I suggest you ...

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.

9,282 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Matthew RowanMatthew Rowan shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    IamStalkerIamStalker shared a merged idea: PLEASE!!!! Add Lamda Expression debugging possibilty, please!!!  ·   · 
    Anonymous shared a merged idea: Support lambdas in the immediate/watch window  ·   · 
    KoenKoen shared a merged idea: Allow use of lambda expressions in the watch, immediate, .. windows  ·   · 
    under review  ·  Visual Studio TeamAdminVisual Studio Team (Product Team, Microsoft) responded  · 

    TL; DR – We’re working on it and we’re super excited about it.

    Hey all,

    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
    Program Manager
    Visual Basic & C# Languages Team


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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!

      • Anonymous commented  ·   ·  Flag as inappropriate

        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 LindqvistAllan Lindqvist commented  ·   ·  Flag as inappropriate

        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?

      • QwertieQwertie commented  ·   ·  Flag as inappropriate

        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 LevesqueThomas Levesque commented  ·   ·  Flag as inappropriate

        @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 LMickael L commented  ·   ·  Flag as inappropriate

        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!

      • SpacemanSpaceman commented  ·   ·  Flag as inappropriate

        Can someone tell me what is "Debug Lambda expressions [Planned]"?
        With Respect "Spaceman"

      • FloeleFloele commented  ·   ·  Flag as inappropriate

        Actually, UserVoice supports a "started" state...maybe you disabled it on your site, but it can be used. Just FYI.

      • Oli PykeOli Pyke commented  ·   ·  Flag as inappropriate

        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.

      • ChrisChris commented  ·   ·  Flag as inappropriate

        Thanks for the update, Anthony. This is a frequent limitation for me, so I'm glad to hear that progress is being made.

      ← Previous 1 3 4 5

      Feedback and Knowledge Base