@Maciejasjmj said in Wherefore `from` in LINQ?:
@Dreikin said in Wherefore `from` in LINQ?:
I was thinking the compiler could reuse thing, but yeah, that might not work as well for everyone else as I thought.
So in the loop body thing is an integer, but in the select clause thing is a ThingClass by design? That would make for very awkward real-life code:
foreach (var index in objectsWithIndices select /*wtf? my index has an index?*/ index.index)
@Dreikin said in Wherefore `from` in LINQ?:
select thing.foo as var foo could work.
foreach (var obj in objectsWithIndices select obj.index as var index)
Hm... it doesn't look right. In "standard" foreach the first declaration from the left is the iteration variable, but in this syntax it's a lambda parameter.
:doh: linq doesn't require var for the first thing. That could solve the "first declaration from the left" thing, but only in terms.
This is why I'm thinking that having foreach loops look more like
foreach (thing in y where thing.foo > 10)
{
// select-like ops here.
}
might be better*, with assignment still as
var z = foreach thing in y select thing.foo;
do is a keyword, but it starts a do...while() loop, so I'm not sure whether this would also be possible:
foreach thing in y where thing.foo > 10 do
{
// select-like ops here
}
I'm thinking do can't occur in that position currently, but I'd have to check the spec to be sure.
It separates pretty well. There's a core section (foreach ...) that is then used for assignment via select, or looping via do.
Interesting..
*: I'm assuming there's other stuff in the loop that justifies not just using select in the first place.
