Consider displaying preview APIs differently

[terrajobst]

With .NET 7, we've added the [RequiresPreviewFeatures] attribute which allows to mark APIs that rely on preview features in runtime, framework, or language. The original spec called out that this feature wasn't explicitly designed for 3rd party use, but that it was in principle possible to be used this way. Since then, we had requests from several parties to make this more usable for 3rd party use, which we're discussing here.

The feature ensures that first time usage of preview APIs will result in an error (raised by an analyzer) unless they explicitly opted into preview APIs. However, after that opt-in is expressed, the normal editing experience in Visual Studio doesn't point out where code depends on preview APIs.

It seems the desire for using this style of previewing is growing. As more parties embrace this style of "piecemeal" preview adoption, we should consider highlighting use of preview APIs in the editing experience of the IDE.

Areas to consider:

• Completion window. Maybe preview APIs should have warning indicator.
• Quick info (tooltips). It would be nice if preview APIs had a warning icon + text right below the signature and before the documentation.
• Editor styles. Maybe preview APIs should be rendered differently in the code editor, for example, by using italics and/or a different color.

Thoughts?

[CyrusNajmabadi]

All of these seem reasonable. Please let @arkalyanms know how important this is for the BCL and what time line you're looking at here for thsi request. Thanks!

[terrajobst]

Great questions; this isn't tied to anything in .NET 8. It's mostly in support of our partners who ship out-of-band, such as the Azure SDK, but of course we're also benefiting from this work for anything we already shipped or will ship in .NET 8. As such, I don't think there is a hard date requirement. In terms of importance: I'd say that should depend on whether we're able to use this attribute successfully for 3rd party consumers, which we're working on right now. Until then, I don't think it's quite actionable for you, and once we have it confirmed we'll be able to attach a priority to it.

Meanwhile, I'm interested to hear any reasons this wouldn't be workable, but it sounds like there is no objection to any of this, which is great :-)

[CyrusNajmabadi]

We're only limited here by what the VS editor supports. And if it doesn't support this stuff, we can make requests on it. That's why importance/dates help here in case we need to put in some requests. But we can certainly do some earlier prototyping to see what's possible.

[terrajobst]

Gotcha. I'll try to get some rough dates/important sorted out for work that includes this; however, it seems likely that a great deal will spill into January (the definition of the dates, not the dates themselves of course)

[sharwell]

⚠️ This should be implemented together with #26488