29

I've seen it said in other questions that the Linq query syntax compiles to a Lambda.

So why can you not do edit-and-continue when there is a Lambda expression in the method, while with query notation you can?

What's most infuriating, and is seriously making me consider switching to using query notation everywhere, is that even if your code is not in the Lambda, but there's a Lambda somewhere else in the same method, you can't edit-and-continue! That's, like, gratuitous pain inflicted upon unwary developers!

Shaul Behr
  • 36,951
  • 69
  • 249
  • 387
  • Agreed. I used edit-and-continue a lot but now I that I use lambdas a lot, it kinda killed that feature. – Meta-Knight Aug 19 '09 at 14:10
  • 1
    possible duplicate of [Why can I not edit a method that contains an anonymous method in the debugger?](http://stackoverflow.com/questions/581967/why-can-i-not-edit-a-method-that-contains-an-anonymous-method-in-the-debugger) – nawfal Jun 18 '14 at 02:37
  • 2
    For those reading in 2016, you CAN do this now in VS2015. There are still some limitations, but by and large they did a great job. – C. Tewalt Jan 22 '16 at 21:44

3 Answers3

23

Edit and continue is able to change method implementations "live", but not what fields are in types.

Lambda expressions (and anonymous methods) can end up creating their own private types when they capture variables. Changing the lambda expression can change the types involved, which would break edit and continue.

It sounds like it should be possible to make changes to the code which don't have this impact, but I suspect it's simply easier to prevent it entirely - which also means you don't start making changes and then find that you're prevented half way through your change.

(Personally I'm not a fan of E&C in the first place, so I've never noticed it.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
0

I don't know for sure, but my guess is the complexity around figuring out what needs to change when there are local variables involved that are lifted to classes. I'm guessing that figuring out what changes would be safe and what wouldn't was deemed to complex and error-prone to get right at this point. The tooling in 2010 focused around threading and the new UI -- maybe we'll get it in the next version.

Jonathan Rupp
  • 15,522
  • 5
  • 45
  • 61
  • why? as long as you're not debugging the method itself, you'd think some new IL would be emitted and the JIT would do its thing when needed. Its not like, say C++ where E&C works even though you'd think it had to work harder. – gbjbaanb Aug 16 '13 at 15:10
0

I don't know it for sure, but I assume it has to do with the way the compiler converts lambda expressions forming closures into compiler generated classes. Probably there is no (easy) way to apply changes made to the compiled code and preserve the current state.

Daniel Brückner
  • 59,031
  • 16
  • 99
  • 143