# Interceptors working group notes for 4th April 2023

The working group reviewed the design doc for the [interceptors compiler feature](https://github.com/dotnet/roslyn/blob/c16a87d4c58a8f6e64f5f6fbb7b885201c7c8dc0/docs/features/interceptors.md), and addressed some of the open questions.

**Are the `[InterceptsLocation]` attributes dropped when emitting the methods to metadata?**

No. Other attributes which are specially recognized by the compiler (which also are not pseudo-custom attributes) aren't dropped in this way. We don't think it's problematic to do the same here.

**Should we permit interceptors declared in file types to refer to other files?**

Yes. We think it's fine for the compiler to intercept with a call to an "effectively file-local" interceptor, even if the call is not in the same file as the interceptor.

One concern that could come up here is: what if the runtime wanted to add a *reified* concept of `file` accessibility? Then, assuming the compiler adopted it, using file-local types in this way it might actually fail at runtime. However, we don't think adding such runtime enforcement is especially compelling, and feel comfortable blocking the ability to add it in the future.

**What kind of user opt-in step should be required to use interceptors?**

Interceptors are in an unusual spot compared to preview features we've shipped in the past.
- We want to use them in *stable/supported* scenarios, including a stable `<LangVersion>`. We think referring to the feature as *preview* isn't quite right, as preview features aren't used as components of *stable* features. This is part of why the label *experimental* was chosen.
- We want them to be an implementation detail of certain source generators. If any opt-in step is necessary, we want generators to essentially be able to do it on behalf of users.
- We want to be able to change them based on what we learn from their usage in .NET 8. In order to get a significant enough amount of usage, we want them to be used in the mainline "ASP.NET Minimal API with NativeAOT" scenario, without the user having to set an extra property in their project, for example.

When discussing what kind of opt-in step to build, we also ended up discussing the entire conception of the feature as "experimental", and the associated set of risks.

One problematic scenario we considered is: what happens when someone installs a .NET 9 SDK someday and uses `<TargetFramework>net8.0</TargetFramework>`. We might be in a situation where interceptor-based source generators from the .NET 8 targeting pack get used, while .NET 9 has removed or changed support for them.

To keep things from failing in that case, we would need to either maintain support in the compiler for as long as .NET 8 is supported, or the generator author (basically, the runtime) would need to service the targeting pack. We think this wouldn't be a problem for generators which ship in the SDK, which are more naturally "synchronized" with the compiler version in use.

It was suggested that it's not extremely problematic for this feature to stay around for the .NET 8 support cycle, or even stay around indefinitely, just because a feature is introduced later that handles the scenarios better.

**Conclusion**

There will be no opt-in step needed to use interceptors.

We think that an opt-in step which is only performed by generators doesn't add enough *safety value* to be justified. Instead, we want to convey in documentation that early adoption of interceptors is risky. We will not *publicize* the feature (in blog posts, etc..) as something third-party generator authors should onboard to at this time.
