Not sure I like having static everywhere even it it's obvious the lambda is not lifting any variables.

I left it out during my first pass, but added it during the second pass. It significantly improves auditability.

I'd rather prefer readability. static is mostly noise, imo.

fwiw i'm flexible. But i'm aligning more with sam in terms of having hte visibility here. It feels like this is a general area that does cause us pain (i've certainly had to fix tons of cases in the IDE where this cost hurt us), and it's why i did the work to add static-lambdas to the language :)

Perhaps we can start here, but then be comfortable allowing devs in their area to judiciously decide if they do/don't want to use this modifier?

As discussed with Sam offline, I think the ideal solution is to have an analyzer that identifies call sites of methods that take lambdas but there is also an alternative that takes a TArg argument passed thru to the lambda as well. That's what we are actually trying to do here - to use the more memory efficient, argument passing version. It might get a bit tricky to identify these methods, but it's doable. If we had such an analyzer there wouldn't be need for using static.

I don't actually find static generally that useful. Yes, it makes it more obvious that you're not creating a closure but how do you know that it's possible to not create a closure in the first place? How does the dev writing code that calls Any (or any other method that takes a func) know there is a version of it that passes thru an argument that can avoid closure creation? Especially since 1) the methods are generally not in BCL 2) our extension methods that fill in the need are scattered across multiple namespaces and often don't even show up in completion.

Adding static to Any lambdas may be fine to address an imminent issue that we observe, but doesn't seem like a comprehensive solution to this problem. I think we should follow up with 1) moving the extension methods to the same namespace as the type being extended, so that they are available at all call sites where the original method is 2) check with runtime and LDM if the compiler can automatically optimize the lambdas if both overloads are available (and maybe marked with some attribute that declares the functional equivalence of the overloads) 3) write the analyzer.

ngl. i hate this code :D