Open jeffhandley opened 1 month ago
Tagging subscribers to this area: @dotnet/area-system-runtime See info in area-owners.md if you want to be subscribed.
/cc @333fred @jaredpar
Spawned from https://github.com/dotnet/runtime/pull/107905#discussion_r1763876212 by @stephentoub
When I designed the attribute I considered that but ultimately decided against it:
DiagnosticId
and UrlFormat
laterI'd say if you want to provide additional context, use DiagnosticId
and UrlFormat
. Whatever this points to can be updated, include sample code, etc.
Thanks for sharing that background, @terrajobst. I can acknowledge all those points and I agree it's an option to keep the status quo and rely on the linked documentation to provide fuller context.
With the [Experimental]
attributes we've applied so far, I instinctively expected to add a Message
to the attribute as it would be visible in IntelliSense rather than requiring docs to be opened and read. For the DivRem
example, it would be nice for message visible inside the IDE to reference the alternate API that isn't experimental. I kind of want to argue that the message from Roslyn is "too scary," but it's probably sufficiently scary.
'{0}' is for evaluation purposes only and is subject to change or removal in future updates.
I think it's a decision of whether we want to provide API-specific, non-localizable, non-serviceable, short messages in IntelliSense, or if we want users to always have to click the link and read the localizable, serviceable, detailed docs.
[Obsolete]
is already subtly different, the constructor might be confusingnamespace System;
public partial class ExperimentalAttribute
{
public string? Message { get; set; }
}
As the author of the original proposal from 5 years ago (which already contained the Message
property) I'd like to chip in with my 2 cents.
I understand and agree with having an external url that allows us to support full blown localization plus the ability, in the online resource, to have longer explanations, rich examples, extra info and things like images/videos.
At the same time though, from a pragmatic perspective, we should also consider other things like:
if
, function
, public
, protected
and so on, and that is because it is the lingua franca on the development world. Inclusiveness is important, but using english as a minimum/baseline language is not problematic, imho, and gives actual concrete help to actual peopleIf developers want, they can always use the external url and localize everything, add images and so on.
Having said that, having an optional english-only message that can be directly used to very quickly give a minimum of context on what is going on is, again imho, a very sensible thing to do that achieves the very concrete goal of providing some context without taking anything away.
Just my 2 cents, hope this helps.
ps: just as a sidenote for future similar developments, starting again today I would have opted for the other way around, meaning mandatory message (minimum effort and concrete immediate result) + optional external url. But still, this is a very welcome and concretely useful addition.
Background and motivation
With our recent adoptions of the
[Experimental]
attribute, we found it would have been valuable to add a custom message for the experimental APIs to add context for why the API is marked as experimental. The desired experience would be similar to that of[Obsolete]
where a custom message can be provided in addition to the custom diagnostic ID.API Proposal
API Usage
Alternative Designs
Create a new mechanism for registering the messages. Or keep the status quo and rely on the linked documentation to provide fuller context.
Risks
We will need to follow the model we applied with
ObsoleteAttribute
where the compiler respects whicheverExperimentalAttribute
is defined for the assembly using it, where that type might haveMessage
or might not. When applying this attribute down-level to targets beforeMessage
was introduced, libraries can opt to include an internal copy of the class that includes the property so the message can be applied.We will need to discuss the format of the compiler message, localization, and determine if the default message should be emitted in addition to the custom message, or if only the custom message would be emitted. We should be able to follow the
[Obsolete]
attribute behavior.