Add interceptors open design questions #67970
Conversation
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
|
|
||
| We specify `AllowMultiple = false` here to imply that the attribute is supposed to be hand-authored by the user. It's not meant for generators to use this to *opt themselves in* to being able to intercept things--it's for the user to state once and comprehensively which things can be intercepted. | ||
|
|
||
| In such a scheme, it's not clear how often users would actually want to go to the trouble of writing the attribute--particularly since the process of writing and maintaining it would simply be to run source generators, review the "not interceptable" errors, and add the related types to this attribute. Is that useful to users in practice? |
There was a problem hiding this comment.
I do not think it is useful.
We can add this attribute in future if we find actual need for it. It would not be breaking change to add it in future.
There was a problem hiding this comment.
To be clear, are you in favor of the below option?
One option to address this is to remove
[Interceptable]from the design and not provide any mechanism for limiting which calls can be intercepted or not.
There was a problem hiding this comment.
I agree it is an item we could add later if there was need.
There was a problem hiding this comment.
I haven't heard any objection to eliminating InterceptableAttribute for the .NET 8 version of the feature, and possibly introducing some limiting mechanism in the future.
I'll merge this PR as-is, but have added a note to the test plan to go ahead and eliminate InterceptableAttribute in this design doc and from the implementation in a subsequent PR.
There was a problem hiding this comment.
Yup, let's get rid of it. Thanks.
| @@ -178,6 +207,8 @@ Although interceptors are an experimental feature, there will be no explicit opt | |||
|
|
|||
| PROTOTYPE(ic): The BCL might not ship the attributes required by this feature, instead requiring them to be declared in some library brought in by a package reference, or in the user's project. But we haven't confirmed this. | |||
|
|
|||
| PROTOTYPE(ic): Feedback from Jared is that we need to have an opt-in step, even if it is only performed by generators, so that any teams adopting this understand the level of support they can expect for this. Most likely, we would do this by checking for `/features=interceptors` on the command line (`<Features>interceptors</Features>` in msbuild). Then generators that want to use interceptors would just ship a bit of msbuild logic to ensure the appropriate feature flag is being passed to the compiler. | |||
There was a problem hiding this comment.
I think this is important if we end up labeling this as experimental for .NET 8. There will absolutely be generators that take advantage of this setting. I don't want to fall into a trap where we label it experimental, have no opt-in mechanism and generators using interceptors reach a critical mass such that we can't change it. Just as customers had to opt into experimental features like DIM, they need to opt into this.
At the same time, I feel like for scenarios like ASP.NET AOT this opt in is implicit. The props / targets in SDK are free to implicitly set this flag such that we have a friction free experience there. Part of deciding this is experimental would be ASP.NET agreeing to adjust the generator to new compiler behavior should we change things. Essentially we're agreeing to own keeping this overall scenario working as a team even if the implementation details change a bit.
Note: this is all still predicated on whether this is labeled experimental or not in .NET 8.
Test plan: #67421