Debug Lambda expressions [Planned]
Allow Quick Watch and other Debug functions to work with Lambda expressions.
"Expression cannot contain lambda expressions" makes this powerful language feature second-class within the IDE.
Especially for data intensive applications being able to write Lambda expressions in the Quick Watch, Watch, Immediate Windows and debug evaluation is a must have.
Now it's not allowed to debug Lamda Expression in QuickWatch, can you please add it?
Using Roslyn, it should be easier to support lambdas in the immediate/watch window. This would be enormously beneficial, as right now LINQ, one of the most powerful tools in .NET is not usable while debugging, which makes debugging with data sets a lot more difficult than it needs to be.
So that it's easier to debug.
TL; DR – We’re working on it and we’re super excited about it.
Just shooting you all an update on this since I can see some of you are wondering if we forgot about this issue. Unfortunately, with UserVoice we can only mark a suggestion as “Under Review”, “Declined”, or “Complete”; there’s no “Planned” or “In Progress” state which is why this suggestion is still marked “Under Review” even though we’ve been working on enabling this for a while.
So here’s where we stand.
1) We want this to work as much as you do. It’s not under review – it’s in progress.
2) We figured out how to make it work; it simply requires rewriting everything.
3) We’re rewriting everything.
4) Rewriting everything takes a lot of time and a lot of testing.
You see, the Immediate and Watch windows are powered by this thing called the Expression Evaluator. This is also the component which powers data tips, DebuggerDisplayAttribute, conditional breakpoints, and object expansion (seeing the values of properties of objects in the debugger) and probably some other things I’m forgetting. The EE parses the code and compiles it to IL (the EE is actually an extension of the batch compiler) which is then sent to some other component to run. That other component actually interprets it to detect (and usually prevent) side effects and has to be taught how to interpret IL that creates new types and methods.
As you all probably know lambdas are implemented by creating new unnamed methods and, if closures are involved, creating whole new types and capturing your context into fields of that type. The existing pipeline has no capability to declare new methods or types. Even if we didn’t support capturing context (which isn’t very useful at all) we still need new types if we want to support anonymous types which are common in LINQ/lambda expressions as well.
Now, imagine the case where you do want to capture a local variable in your lambda. At compile time this is relatively easy because we just rewrite the method while compiling. But now we’d have to rewrite the method for the current stack frame to have all of the closure classes that weren’t there when it was originally built but not actually modify your running problem (because the closure only exists in the pocket dimension that is the watch window). This is doable but crazy hard (not like hard-to-do-right-but-we-can-hack-it-in-over-the-weekend hard – it’s crazy hard) and requires collaboration between the managed languages team and the debugger team.
Add to this that we’ve been rewriting the compiler since 2009. We could potentially update the existing component to support lambdas but that would be an insane amount of wasted effort. Because we’re evolving the “Roslyn” compilers and adding new features there. So even if we want to support lambdas in the old EE we wouldn’t support new features we’re adding now like the ‘?’, operator. We could teach that old stuff about ‘?.’ but what if we did string interpolation? We don’t want to be in the situation we’re in now where language improvements never make it into the expression evaluator nor do we want to maintain two compiler versions forever so we’re rebuilding the EE on the “Roslyn” compiler. Our team rebuilt the compilers, we’re rebuilding the IDE, and rebuilding the expression evaluators (incidentally we’re also rebuilding the thing that makes Edit & Continue work) and that’s taking an understandably long time.
The exiting news – it’s pretty far along but there’s still work before we can retire the old component (remember – it’s not just enough that a new EE support lambdas they also have to support everything else that the old EE supported) before we would replace the old EE in VS and put it in your hands. We understand that developers spend a tremendous amount of time debugging in Visual Studio. It’s a mission critical activity and we’re just doing our due diligence to make sure we continue giving you that same great quality experience.
I look forward to the day when I can announce it’s ready. In the meantime, I thank you for your continued trust and patience.
Anthony D. Green
Visual Basic & C# Languages Team
Superb news. Thanks for listening.
Edgar Salazar commented
'ppreciate it, mates.
Eduardo Pires commented
I can't wait to see it working...
Thanks for the updates and we are all looking forward to use it.
Don give up ! Common Lisp compilers had such possibility from day one. I tired to restart my project every time i modified something in method with lambda function. You should rewrite everything indeed if it help to implement the feature!
Very excited about this. This will save hours and hours of time. I hope you guys go all the way and replace the Immediate Window with the REPL that was in the earlier Roslyn preview. Great work!
Allan Lindqvist commented
Awesome news! running on rosyln is absolutely the way to go even if it's alot of work now, it will definitely be worth the wait :D
will it still make it into v.next do you think?
We're all glad you're working on this, but I find it puzzling that you guys didn't implement a stopgap solution, say, 5 years ago--something that would let you write lambdas but not closures and not new types. Yes, a simple "list.Where(x=>x.Foo > 100).Select(x=>x.Bar)" is VERY useful and it sounds like everything didn't have to be rewritten to support it.
It would have been independently useful (whether lambdas are supported or not) to be able to effectively change the DebuggerDisplay attribute from within the debugger itself, without changing the code or restarting the session.
Thomas Levesque commented
@Mickael L, I think you misunderstand what this is about. This is about supporting lambda expressions in Watches, Immediate Window etc. It's *not* about allowing edit and continue for lambdas ; you can already modify a method that contains lambdas, as long as you don't change the lambda itself.
Mickael L commented
Good news !
I hope a lot developpers will stop thinking that lambdas don't have to be used because they can't debug them without restarting!
Can someone tell me what is "Debug Lambda expressions [Planned]"?
With Respect "Spaceman"
Great to get the update that things are in progress.
Eyal Shilony commented
Great to hear! :)
Ten awesome points for the update.
Actually, UserVoice supports a "started" state...maybe you disabled it on your site, but it can be used. Just FYI.
Oli Pyke commented
Wow, that is the sort of update we need! Keep going, we will love you forever once this is in. Not that we don't already.
Awesome. Keep up the good work!!
Awesome freaking update! Thank you.
Thanks for the update, Anthony. This is a frequent limitation for me, so I'm glad to hear that progress is being made.
Vitor Canova Weingaertner commented
Thank you guys for start introduce it into Visual Studio. I have been missed it for years.