decltype(auto)

While trying to add an ESP-IDF Runtime for this library (instead of forcing the Arduino one to be used), I've run into the `Servo` library being a runtime environment boundary;...

Let's not ask me for suggestions on that first class problem else I'll end up proposing CRTP... Well I am not using the Arduino Framework **at all**, which rules out...

That's exactly what I have right now: a polyfill for the two functions currently used by the library If we choose to put the Servo stuff in the Runtime abstraction,...

Correct; that does cause the problem of ownership however (i.e. how does `ServoMotor` know how to correctly handle `mServo` on destruction?) ~~It does however allow one to use the library...

> In other words, if there is a Servo it is always there and so is "the runtime". As I see it, these classes don't get destructed. If you only...

I'll keep this conclusion in mind and will adapt my current polyfilling. I'll get back to you once I'll have managed to successfully write my runtime impl if you're interested...

- String literals: yes - Templates also cover template aliases and template variables - `struct` does not define a product type since you cannot sum two structs - `type_traits` contains...

Now onto step n°2; I'm searching for existing zlib tests (so far I found the golang one), as well as places in Beast's zlib that need some test cases. If...

Actually, would you prefer the compressor/decompressor abstractions to be based off an abstract base class or to pass templates around ? (i.e., should the abstraction request the abstracted context at...

Okay; good thing I already did that, and was just waiting for your answer to go ahead and apply it on the tests