It adds absolutely nothing, that's why it should not be accepted. It will
lead to a divergence in the way it's used as well. However I think maybe
run block once before first condition check would be a useful and powerful
addition. Maybe it shows my age that I even know what do-while
post-conditional loops are, and why they are useful. I have had to write
these more wordy constructs for exactly this purpose several times in a
project I am working on.
If there could be some less verbose way to flag that the condition only be
checked first run. As I am thinking about it I am thinking of some other
ways too, such as adding an or clause in the conditional that only checks
if it's the first run, since golang's and and or operators are just
drop-throughs, well, more or less, I mean, the or operator just does both
tests and runs the block directly if the first condition passes. Here's a
rough sketch of it while I am thinking about it
for w:= true; w || <cond>; w=false {
...
}
This will always run the first time and I can't be certain but I think that
the compiler may skip the assignment second time since it is an assignment.
Still wordy but it is a do-while loop, nevertheless. If the assignment is
repeated each time it's still an overhead cost, however. Some kind of 'do
this only once' hint to the compiler maybe. But you see what I mean. This
is definitely a case of something Go could use as an improvement and if it
was constructed correctly it would not break old code, but instead actually
give people a way to improve it when refactoring later on.
On Wednesday, 2 May 2018 20:43:11 UTC+3, Ian Lance Taylor wrote:
>
> On Wed, May 2, 2018 at 2:48 AM, Hugh Fisher <hugo....@gmail.com
> <javascript:>> wrote:
> >
> > On Tuesday, May 1, 2018 at 10:45:30 PM UTC+10, Ian Lance Taylor wrote:
> >>
> >>
> >> A `while` statement would presumably be exactly identical to a `for`
> >> statement with a single condition. So adding a `while` statement
> >> would not add any power to the language, and would add an additional
> >> keyword. All language choices are a cost benefit decision. In this
> >> case the benefit is a looping construct that some people will find
> >> clearer to read and write, and the cost is a new keyword that
> >> everybody needs to learn, and that at this point in the language's
> >> evolution will likely break some, even if not much, existing code. I
> >> don't think the benefit is worth the cost.
> >>
> > As for not adding any power, that's why I mentioned if-then-else and
> switch.
> > Switch with boolean cases is the same as if then else. It's not an
> obscure
> > side effect either, the Go Tour cheerfully explains how to use it
> instead of
> > if-then-else if you prefer.
>
> That is not the same thing, though. Yes, if-then-else and switch do
> similar things, but they have a different syntax and are idiomatically
> used in different ways. You can consider if-then-else as syntactic
> sugar for switch, if you like. It's OK for a language to have some
> syntactic sugar.
>
> But in this case you seem to be suggesting that we add `while <cond> {
> <body> }` as an exact duplicate of the existing language construct
> `for <cond> { <body> }`. That's not syntactic sugar. You are
> suggesting that `while` just be a synonym for `for`. We don't need
> two different keywords that mean exactly the same thing.
>
>
> > Hmm, think I will have a look at the formal change proposal process...
>
> I encourage proposals but I can tell you upfront that this proposal
> will not be accepted.
>
> Ian
>
--
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.
