#6583 is breaking change - developers should know.

[mathertel]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have checked that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

The topic

There was a change should be listed under breaking changes as you have to re-write the parameter on any handler overriding the existing functions. If you have no override annotation it even does compile - but do not work.

Was introduced in #6583

As there is no example where a class is deriving from RequestHandler this is not detected in builds.

[Hieromon]

@earlephilhower, Is it possible to notify other library developers of such significant changes in advance?
You say RequestHandler is basically private, but I understood it was the public way to make the RequestHandler implementation. (That's why I used that utility)

[earlephilhower]

@Hieromon while it does look like this escaped notice as a breaking change, it was in the development repo for almost a full year before the 3.0.0 release, which is really the only way we have of letting the world know where the repo is going.

@mathertel we can add a note on the next bugfix about this, sure. Because this is a 2.x -> 3.x transition, breaking changes are expected, but looks like we missed a note about this.

[mathertel]

Thanks.

[mathertel]

Here is a code snipped to declare the function so they can be implemented using the same code:

#if defined(ESP8266)
  bool handle(WebServer &server, HTTPMethod requestMethod, const String &requestUri) override
#elif defined(ESP32)
  bool handle(WebServer &server, HTTPMethod requestMethod, String requestUri) override
#endif

Same for upload, canHandle and canUpload

[Hieromon]

I reluctantly adopted the following implementation to ensure backward compatibility with my library. It's an incomplete method that relies on fixed member function signatures and is verbose if I try to write it completely.
Is there a better alternative to this way?

template<typename T>
struct TypeOfArgument;
template<typename T, typename U, typename... V>
struct TypeOfArgument<U(T::*)(V...)> {
  template<size_t i>
  struct arg {
    typedef typename std::tuple_element<i, std::tuple<V...>>::type  type;
  };
};

// Determines the type of the uri argument contained in the member function
// signature of the RequestHandler class. This redefinition procedure ensures
// backward compatibility with ESP8266 arduino core 3.0.0 and later.
// However, it relies solely on the canHandle member function as a criterion
// and lacks completeness.
using URI_TYPE_SIGNATURE = std::conditional<
  std::is_lvalue_reference<TypeOfArgument<decltype(&RequestHandler::canHandle)>::arg<1>::type>::value,
  const String&,
  String
>::type;

Class Foo : RequestHandler {
 public :
  Foo(){}
  ~Foo(){}
	
  bool canHandle(HTTPMethod requestMethod, URI_TYPE_SIGNATURE requestUri) override;
  bool canUpload(URI_TYPE_SIGNATURE uri) override;
  bool handle(WebServerClass& server, HTTPMethod requestMethod, URI_TYPE_SIGNATURE requestUri) override;
  void upload(WebServerClass& server, URI_TYPE_SIGNATURE requestUri, HTTPUpload& upload) override;
};

Initially, I tried to use esp8266::coreVersionNumeric, which is the recommended method for absorbing version, but constexpr parseNthInteger can not be used in the class member function declaration in order to be evaluated at the same timing as the instantiation of the template.

[d-a-v]

Would a global define restoring the old-and-esp32-compatible API help ?
(something like #ifdef COMPAT_ESP32 or #if COMPAT_ESP32 >= 10001 // >= v1.00.01, you would have to use a global #define COMPAT_ESP32 10001 in your project)

[d-a-v]

Closing this issue per following actions

• Breaking change list summary for 3.0.0 has been updated to highlight Pass String by const reference [3.0] #6583
• Release described by #defines have been added and will be available for release 3.0.1

[Hieromon]

@d-a-v In conclusion, I find it difficult to completely eliminate the legacy method of relying on #define to satisfy static type determination in C++11 as a way to keep backward compatibility. It detains us.
These problems are common in infrastructure components that have been in use for a long time, but at the same time prove that they are valuable.
Anyway, thank you for your support.