yes I made a bunch of errors in my examples... no need for outer scope
declaration with initialiser in the initialiser clause (one or the other,
you know what I mean)
There is a reason why in Go an assignment statement does not also evaluate,
but I am not aware of it, and this excludes this from the for grammar
because the first clause is a statement not an expression, the second is an
expression, and the third is a statement.
On Thursday, 3 May 2018 12:47:38 UTC+3, Louki Sumirniy wrote:
>
> I am writing code in which I pondered exactly using this kind of thing, it
> involves tree walking on a binary tree, but I decided to scrap this
> approach because, although you can't see it so clearly in that C code, it's
> executing a function every loop that probably doesn't need to be. your
> next() function sounds like an iterator and you could just use range
> instead, and slices. This is most likely why this use case has been
> rejected as it does not improve the expressive power of the statement.
>
> On Thursday, 3 May 2018 11:25:34 UTC+3, rog wrote:
>>
>> FWIW, the thing I miss sometimes is the equivalent of C's:
>>
>> while((x = next()) != nil) {
>> something()
>> }
>>
>> In Go you need to do either:
>>
>> for x = next(); x != nil; x = next() {
>> something()
>> }
>>
>
> I dunno if that's an error but since you are in this code above working on
> a variable in the parent scope it would make more sense to combine the
> declaration and initialisation outside the for block scope, as you have
> left out a necessary var type declaration and in that case you could
> shorten that by type inference declaring it prior to the for loop. You
> would have a point if the declaration of x was in the first clause but even
> then x := next() is visibly different to x=next() and alternatively even
> you could shorten this by using indirection. For example, I would implement
> this logic thusly:
>
> func next(x *Xtype) {}
> func first() *Xtype { <create here, eg return &Xtype{1, 2, 3}> }
> ...
>
> then
>
> var x *Xtype
> for x:=first(); x!=nil; next(x) { }
>
> since after all, this next() function is semantically (human-wise)
> ambiguous and doesn't express any relation to the nature of the list it
> must refer to. Slices let you do this iteration even neater using range and
> I am wondering why you can't use slices
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
