Date: Thu, 11 Mar 2021 17:14:41 -0500
Hi,
I would like to propose an attribute [[experimental(msg)]], with similar
semantics to [[deprecated(msg)]]. Even on (or specially on) stable
libraries the developers may wish to introduce a new type or function to
their libraries, but are uncertain if this is the final form the addition
would take.
Some users of such libraries may want to receive a diagnostic when using
experimental features. Other (more adventurous types) may be Okay with
adopting not-quite-fully-baked features. Abusing [[deprecated(msg)]] for
this purpose almost works, but has some clear disadvantages:
- It is obviously the wrong annotation, a casual reader may draw the wrong
conclusion.
- The compiler diagnostics typically include the word "deprecated" which is
confusing.
- Users of the library may wish to receive diagnostics about deprecated
features, but may be Okay with using new experimental features.
Having a new attribute would obviate these problems and give
library developers a path to introduce new functionality, with sufficient
diagnostics for folks that prefer to avoid them.
Regards,
I would like to propose an attribute [[experimental(msg)]], with similar
semantics to [[deprecated(msg)]]. Even on (or specially on) stable
libraries the developers may wish to introduce a new type or function to
their libraries, but are uncertain if this is the final form the addition
would take.
Some users of such libraries may want to receive a diagnostic when using
experimental features. Other (more adventurous types) may be Okay with
adopting not-quite-fully-baked features. Abusing [[deprecated(msg)]] for
this purpose almost works, but has some clear disadvantages:
- It is obviously the wrong annotation, a casual reader may draw the wrong
conclusion.
- The compiler diagnostics typically include the word "deprecated" which is
confusing.
- Users of the library may wish to receive diagnostics about deprecated
features, but may be Okay with using new experimental features.
Having a new attribute would obviate these problems and give
library developers a path to introduce new functionality, with sufficient
diagnostics for folks that prefer to avoid them.
Regards,
-- Carlos O'Ryan // -fno-exceptions delenda est
Received on 2021-03-11 16:14:55