# C# Language Design Meeting for February 27th, 2023

## Agenda

- [Interceptors](#interceptors)

## Quote of the Day

- "Interceptors, that sounds like those auxiliary ships to Star Destroyers"

## Discussion

### Interceptors

https://github.com/dotnet/csharplang/issues/7009

Today the LDM took a look at a new proposal in collaboration with the ASP.NET team, interceptors. This feature is
intended to help make code AOT-friendly by allowing source generation to replace runtime reflection. By doing static
analysis at compile-time and then hooking APIs, we can both improve performance and remove AOT-unfriendly code. This
proposal generated significant discussion in the LDM, with roughly two ideological camps forming:

1. Interceptors are intended to be a performance optimization step. Generalized aspect-oriented programming is not
   a goal of the proposal, and the mechanism they work by is effectively an implementation detail. Users should not
   need to know that a method has been intercepted, so long as the debugging experience works well.
2. Interceptors are a generalized language feature, of which AOT-optimization is just one possible application. Users
   should know when a method call has been intercepted: perhaps they need to indicate this by putting a sigil at the
   callsite, such as `#` (ie, `controller.MapGet#("/", CreateFeed)`).

Not everyone fit into these precise camps, but these were the general sentiments. Some other ideas that were raised
during the meeting:

* Can this be addressed by an IL AOT-rewrite tool instead of a C# language feature? By causing the C# compiler to
  emit different IL, it needs to be a language feature; if it was instead an additional step after compilation, then
  it no longer needs to affect the C# specification, and is not restricted to C#. As a C#-only feature, it could
  negatively affect the F# and VB ecosystems.
* These hooked functions are really much more powerful than what can be accomplished today: state from the entire program
  can influence them. Maybe this calls for a different calling syntax entirely?
    * Lots of examples in other languages both for and against this: Rust uses the `!` character, while LISP does not
      have a different syntax.
* Should we restrict these to just methods? Could you intercept properties, events, fields?
* How general-purpose are we aiming for here, and is there any reasonable way to restrict it to only being a performance
  optimization step even if we decide that it should only be used for that? As the saying goes, if all you have is a
  hammer, everything is a nail...

We did not come to any conclusions today; indeed, this conversation generated more post-meeting chatter in our Teams
chat than any LDM topic in recent memory. It's clear that we need to think more about the problems that were raised today
and come back with a revised proposal that takes these questions into account.
