search

dotnet / roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
https://docs.microsoft.com/dotnet/csharp/roslyn-sdk/
MIT License
18.92k stars 4.02k forks source link

Consider displaying preview APIs differently #65915

Open terrajobst opened 1 year ago

terrajobst commented 1 year ago

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:

Thoughts?

CyrusNajmabadi commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

⚠️ This should be implemented together with https://github.com/dotnet/roslyn/issues/26488