Added: LDM Notes for November 3rd, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-11-03.md

Agenda

1. Name shadowing in local functions
2. params Span<T>

[MgSam]

Definitely the most exciting quote day you guys have had.

We regret that simultaneous capture/shadowing was allowed, and now it's too late to really fix it.

Why not fix the name shadowing in local functions using a warning wave? It's not like its a difficult fix for people to make when upgrading C#.

[CyrusNajmabadi]

We conisidered, but just decided we had more important fish to fry (and we don't want to necessarily maintain that code). So we leave it as an option for someone to bring as an analyzer (Roslyn-Analyzers would be great for this).

[AartBluestoke]

"Not doing any kind of optimized IL in C#, and relying on the JIT to perform the escape analysis and translation from array to stackalloc when viable."

• it would be nice for the language design team / compiler team to come to a conclusion here : is it the responsibility of the language to provide hints, libraries to provide some type of plugins to handle this, or the JIT to an escape analysis module ; a resolution here which would allow better devirtualisation, tail call recursion, cost free linq, stack alloc of small objects, etc
  -- several discussions of the above discussions have stalled at escape analysis.

[huoyaoyuan]

Not doing any kind of optimized IL in C#, and relying on the JIT to perform the escape analysis and translation from array to stackalloc when viable

I dislike these approaches for the reasons:

• It increases the overhead of JIT, of course.
• It requires the user to verify the optimization get applied. The user may not be so confidential about this.

[smoothdeveloper]

I like the approach where the JIT is also able to optimize IL generated by compilers in general.

I gather one concern is that implementing new optimisations like this in a compiler comes with risk of breaking existing code, while the JIT team definitely has the requirement to do stack optimization helped with escape analysis etc. Such risk versus refining C# in other ways (while being open to add such optimizations if they are contributed and the implementation deamed robust) is maybe a tension?

As a fair example, I think some of the optimizations that could look similar to what is discussed here, in F# compiler, have led to code compiled in "Release" having a bug, until the compiler got a fix release. Bugs like this can be worked around (compiler version or tweaking code to not exhibit the IL output issue) but I assume circumstances exist where they remain uncaught till much later (than a compiler error, which is most lucky case).

Sparing the C# team from those considerations by relying on the robust JIT, in order to focus on other language features that yield more benefit overall, seems fine.

It requires the user to verify the optimization get applied. The user may not be so confidential about this.

As I may overlook things (trying to catchup with concept of params Span<T> and what is explained about params T[]), do you mind putting a small C# sample in context, to better understand which kind of code requires attention as to the IL emitted from C# and how the JIT optimizes it.

I understand that checking things post JIT is more work than checking the IL post C# compiler, and we'd like more optimisations, eventually.

[Joe4evr]

There's been talk of wanting some kind of post-compile IL Optimization since 2016: dotnet/roslyn#15929

[hez2010]

• It increases the overhead of JIT, of course.

This won't be a problem since we have tiered compilation now.