Why not just a generic compiler diagnostic message mechanism?

[[diagnostic(level, msg)]]
Where level in { info, warn, error }

Relieve the compiler of the need to care about the reason.

This would allow an easy progression from notification to potential build failure to certain build failure.

Sent from ProtonMail Mobile

On Thu, Mar 11, 2021 at 3:14 PM, Carlos ORyan via Std-Proposals <std-proposals_at_[hidden]> wrote:

> 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,
>
> --
>
> Carlos O'Ryan
> // -fno-exceptions delenda est