Dmitry Arkhipov

I'm not opposed, but there is the issue of invalidating user code. `optional` doesn't implicitly convert to `T*`. So, changing the return type would break every user who didn't use...

I can try

I've discovered these projects that currently use JSON's `if_contains`, and would be broken by the change: * https://github.com/allesafe-com/beng-proxy/ * https://github.com/CdecPGL/PlanetaMatchMaker/ * https://github.com/CM4all/libcommon/ * https://github.com/DyXel/Multirole/ * https://github.com/gmarino2048/circuit-simulator/ * https://github.com/guard3/GreekBot/ * https://github.com/nn6n/beng-proxy/...

Dependency on Optional would also add dependency on Detail, Utility, Preprocessor, and Io. All fairly small libraries. If we go with this, we will not add a config option to...

I have a WIP branch (locally) that _adds_ accessor functions that return `system::result` and _not_ optional. Why add? I decided that changing all of the pointer-returning functions would be too...

#941 adds accessor functions that return `system::result`. I decided against changing existing functions, because I considered that change to be too disruptive. So, closing as "not planned".

Can you elaborate?

I don't see anything particularly wrong with it.

First, what is "'underlying' value"? Second, at first I thought that I forgot to document that conversion happens from **described** enumerators. But I did document it. So, everything works as...

That's a type, not a value. What's the behaviour you expected?