ContextQMD
Back to Csharplang

C# Language Design Meeting for February 27th, 2023

meetings/2023/LDM-2023-02-27.md

latest2.9 KB
Original Source

C# Language Design Meeting for February 27th, 2023

Agenda

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.