this post was submitted on 15 Jan 2025
88 points (98.9% liked)
Programmer Humor
32893 readers
941 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The WTF in the C# example seems to be that people don't understand anonymous functions and closures?
Some of the examples seem to be more "unintuitive for newbies", but there are still some good ones in there
Yeah. I didn't understand what they meant by the wtf there. Seemed to me someone wondered if the Action would have a localised version of i (making this stay lowercase on a phone was harder than it should be) or if it used the same i. So made a simple test for it.
Not really sure it's a wtf unless they expected a different result.
I think the explanation they provide is a bit lacking as well. Defining an anonymous function doesn't "create a reference" to any variables it uses, it captures the scope in which it was defined and retains existing references.
Go had the same behavior until recently. Closures captures the variable from the for loop and it was a reference to the value.
They changed it because it's "common" in Go to loop over something and run a goroutine that uses the variable defined in the loop. Workaround was to either shadow the variable with itself before the loop, or to pass the value as an argument.
It's been a long time since I wrote c# so idk if the same is expected from the avg dev, but in Go it's really not explicit that the variable will be a reference instead of a plain value
i
is still a value type, that never changes. Which highlights another issue I have with the explanation as provided. Using the word "reference" in a confusing way. Anonymous methods capture their enclosing scope, soi
simply remains in-scope for all calls to those functions, and all those functions share the same enclosing scope. It never changes from being a value type.