You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Such a definition won't be perfect because we can't be certain that encode_one() will be valid without knowing the exact range type that will be used until we actually call it, but one can make a very close approximation using concept archetypes.
The text was updated successfully, but these errors were encountered:
This is meant to be a C++17 library so I can't really write concepts and I'm not quite ready to take the pain of "Write a Macro Layer to separate concepts from typical SFINAE and then use that".
That being said, I'm definitely going to be writing this kind of thing for the Standards Paper, so it's probably good to at least put it in the documentation somewhere.
Hell, I can probably put some of this into a cxx20/ subfolder so that at least people can include that directory intentionally and use some of these concepts directly. I can also probably "promote" some of those concept checks into the global namespace and make them is_..._v things by-default for C++17. Probably won't help too much with the overload resolution shenanigans...
Is there an intention to add library concepts in place of the current named requirements?
There's admittedly some challenges in doing so, but I enjoy the benefits of clearer error messages and simpler overload sets.
e.g.
Such a definition won't be perfect because we can't be certain that
encode_one()
will be valid without knowing the exact range type that will be used until we actually call it, but one can make a very close approximation using concept archetypes.The text was updated successfully, but these errors were encountered: