C# I hate you for that!

What if you wanted to use the outer comment variable in the lambda? I think the language is okay.

Js ftw lol

Language is fine. The fuck are you complaining about?

@Lensflare I hate you for that!

White theme is not C#'s fault but your own

Everyone knows the proper lambda param is x.

looks very ok to me

You cannot use the outer comment variable in the labda because it is not even assigned a value before the lambda executes.
It makes no sense for the compiler to demand a different variable name.
It only encourages the use of inproper lambda param names like x.

@flake Know the language. I know it more than most of the morons not able to comprehend what i am complaining about. And I know other languages that behave differently in this case. Just because you think it is normal and expected because you learned that it is how it is, doesn't mean I can't hate it.

@Lensflare Namecalling others with a rant like this is a stellar display of irony my man. I’m amused.

@grumpyoldaf I'm sorry. It makes me angry when people don't even try to listen and think that I just don't know the language. It even isn't the point. Like @flake who suggested I should learn the language and then appearently removed his comment.
To make it clear: My rant is not about why c# does that. It is about that it is shit to do that.
That is my rant. No need to make it look like I don't know what I am talking about like many did.

@Lensflare he removed his account (one of his many)

@Lensflare I understand what you mean. Is it a hassle to have to use different names? Yes. Would it be worse to be given the ability to unknowingly hide a variable you had maybe 4 scopes before? I personally think they made the right choice not letting us use the same name.
I often prefer when they try to protect me from my own forgetfulness :)

@dozingncoding I would agree if the declaration of the outer variable would be one line earlier. But in my example, the inner and the outer variables should not have access to each other. So it should be ok. C# obviously does something special in this case which forbids this code to compile. But I am pretty sure it is some technical reason.

I love it when the compiler is protecting me from making subtile errors but this one is the compiler being annoying for some subtile technical c# implementation reasons. 😌

@Lensflare but lines make no difference in c#

@highlight
//this line
var comment = aggregate.Comments.Single(comment => comment.Key.Id == commentId);
//is exactly the same as
var comment = aggregate.Comments
.Single(comment=>comment.Key.Id == commentId);

@dozingncoding I know. I meant of course one statement earlier.
😌
Comment comment;
comment = aggregate.(...);

Oh this highlight bot looks useful 😄

@Lensflare You know that these two are equivalent to the compiler, right?

@Krokoklemme are you sure? That would explain some things. I know for a fact that it is not the same for the Swift compiler, for example. Just in case you are assuming it to be a normal or obvious thing.

@Lensflare yeah, pretty sure. The resulting parse tree should be the same in either case

idk about Swift though, maybe it does some extra stuff to distinguish them?

@Lensflare Shadowing variables is generally a bad idea. Why do you think that it's better to support it by adding a special compiler rule?

@Lor-inc sorry but you just misunderstood this like most of the others.

This is not the classic case of shadowing. The variable is not accessible outside but can't be redeclared either. That is what I find silly.

I just tried to reproduce it and ... it works now. Maybe it was a bug that has been fixed now.

Anyway, it just confirms that the previous behavior was bullshit. And the people trying to defend it just wanted to sound smart.