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.
