

What else is new in c# 5 - yread
http://www.mindscapehq.com/blog/index.php/2012/03/18/what-else-is-new-in-c-5/

======
robgough
As interested as I am in this, I decided to pass thanks to that share bar.
Seriously awful.

~~~
kyberias
Not that I want to defend it but could you elaborate what exactly is so awful
about it that it distracted you from reading the article. I didn't event
notice it myself.

~~~
BarkMore
I see a vertical bar floating over 15 lines of the body text. I found it
annoying to scroll the page to read around the thing.

------
galactus
The author seems to find that lambdas capturing the same loop variable is
counter intuitive, but, honestly, that's the behavior I would expect from it!

~~~
joelangeway
I confess to making the mistake many times of thinking that I was capturing a
value when I was capturing a variable, but the author has me confused and
concerned that the semantics of lambdas have been changed such that a lambda
always captures the value and not the variable. Capturing variables is darn
useful and more general than capturing values. It would be totally unlike MS
to break all of my code as much as I wish they would in other cases, so I'm
going to assume that they've done something more clever than that.

~~~
galactus
Exactly, I also find it a bit confusing. I assume they are capturing variables
(it would be crazy otherwise!) but they treat loop variables differently (as
if a new variable was created every time).

~~~
noblethrasher
Yes, they are now creating a new variable in the `foreach` loop each time.

They aren't doing the same for regular `for` loops so their behavior with
respect to lambdas won't change.

~~~
TheNinjaneer
To add to this, Eric Lippert, a principal dev on the C# compiler team,
mentions this in a StackOverflow response
(<http://stackoverflow.com/a/8899347/59111>). He also blogged about the issue
in general in a two part series, the first of which can be read here: Closing
over the loop variable considered harmful
([http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi...](http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-
over-the-loop-variable-considered-harmful.aspx)).

------
Strilanc
There's a couple notable omissions from C#5, with respect to what was
implemented in VB.Net.

\- No anonymous iterator functions. They are useful for correctly implementing
iterators with eager validation and lazy iteration.

\- No type inference when assigning an anonymous function to a local.
Determining and typing out a function's type is incredibly slow compared to
just 'var'.

~~~
magic_haze
hmm.. I agree, (1) definitely is a common pattern, and it is often annoying to
write a separate function just to do the lazy iteration. Also really needed:
code contracts within delegates. You can write them now, but the tool can't
recognize them yet.

~~~
sixothree
An ~60x240 box hovering over the text with only the word 'tweet' in it.

------
jawher
Is it just me or does anybody else think that polluting your code with
debugging and logging informations is not such a good idea ?

I understand the value of these informations, but changing your method
signatures to take them is going too far in my opinion, especially that there
a a less obtrusive ways to achieve the same functionality: stack traces. I'm a
Java developer, so I don't know the equivalent in C#, but in Java, you can get
the stack trace (or call stack) of the current thread:

    
    
        Thread.currentThread().getStacktrace()
    

Which will return an array containing all the info you'd like, with method
names, line numbers and file names.

~~~
ppog
In .NET, you can just do "new StackTrace()" to capture the current stack of
the calling thread. One minor risk with this may be if an optimiser has elided
function calls (e.g. converted to a tail recursion). I'm not sure how
realistic this is in the C#/.NET case, but having the information injected by
the compiler eliminates the possibility.

Also, .NET stack traces only contain line numbers if the debugging symbols are
deployed. With the attributes, the C# compiler can inject line numbers at
compile time, obviating the need for symbols. Similarly, if a vendor uses an
obfuscator, the stack trace will include obfuscated names but the compiler
attributes will have injected the real names, making it much easier for
developers to read the log files.

Finally, for scenarios like INotifyPropertyChanged, having the caller name
injected at compile time is much more efficient at run-time than capturing an
entire stack trace just to figure out which property setter is running. This
may not a big consideration for logging, but for property setters it is
definitely worth bearing in mind.

------
politician
I don't like the fact that the value of the parameters associated with the
Caller* attributes can be overriden by callers because they're implemented as
a special case of optional parameters.

On the other hand, if the mechanism by which the Caller* attributes work is
extensible, it may be interesting to use the feature to provide alternate
default values for arbitrary optional params (e.g. non-const default values).

On the other other hand, maybe changing the semantics of default value
assignment is a symptomatic of language bloat.

------
edwinnathaniel
Honestly, I'd like to see Maven/more tools in .NET more than language features
for a very good reason: all the niceties of these new language features don't
seem to contribute much to most .NET projects somehow.

Either people aren't using it, or the type of software that uses .NET don't
need it, or the 98% programmers simply ignore it, or something else that I
don't know/can't point them out.

So please Microsoft, give us Maven for .NET. NuGET and MSBuild aren't enough.

~~~
kodablah
Maven is a bad dependency/package manager because of the complicated nuance,
XML, etc. Java 8 is even planning on using Project Jigsaw to get rid of it
(IIRC). Something like Grape or Buildr would be a better model.

~~~
jawher
> Maven is a bad dependency/package manager because of the complicated nuance

What nuance ?

>XML

Fair point. I don't know what they were thinking when they decided not to use
attributes, but come on, XML is not that bad.

> Java 8 is even planning on using Project Jigsaw to get rid of it (IIRC).

 _Wrong_ : Jigsaw is a modularity tool, maven is a build tool. Jigsaw is
intended as a competitor to OSGi, not maven. Jigsaw won't compile your
project, resolve your dependencies nor deploy your product.

> Something like Grape or Buildr would be a better model.

I beg to differ. I'm no big fan of maven either, but the idea behind it is
pure genius, i.e. an implicit source layout and build lifecycle. Where in
imperative tools like ant and co you'd need to repeat again and again the same
snippets, compile all those files in the src dir into a bin dir, copy a bunch
of resource files to the bin dir, package the whole thing in a jar or a war,
place it in a target dir. Also, the dependencies management used to be a
tedious task, with you hunting for the correct versions of jars, placing them
in a lib directory, going as far as to version them. Most tools now tend to
emulate maven's way of dependency management.

Nothing like this with maven: you just place your code and resources in
standard locations, create a pom.xml file with just infos regarding your
project (name, version and type), possibly the dependencies, and with standard
commandes (mvn install for example), it will fetch the dependencies, build
your porject, package it and install it.

Maven has its warts: verbose XML, unexpected behaviour in some cases, hard to
customize (mostly when you try hard not to follow the standards), etc. But
these are minor and fixable issues compared to the value it provides to
countless developers who could fetch a project source and build it with one
standard command.

------
Tarks
Thanks for writing this, I hadn't yet seen the method caller stuff.

------
leon_
wow, that share thingy is ultra annoying.

