On 2 May 2018 at 22:06, Michael Jones <michael.jo...@gmail.com> wrote:
> Ok, weird proposal: Make the per-iteration update part of a for loop change
> from "assignment to assignment or boolean expression" to allow:
>
> while COND do {...}:
>
> for i:=0; x[i]<4; {...}
>
>
> do {...} while COND:
>
> for i:= 0; ; x[i]<4 { ...}The per-iteration part already allows arbitrary expressions (they might even be bool-valued) https://play.golang.org/p/Nt9woI7EWRP > > On Wed, May 2, 2018 at 12:33 PM Louki Sumirniy > <louki.sumirniy.stal...@gmail.com> wrote: >> >> 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> 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. > > > > -- > Michael T. Jones > michael.jo...@gmail.com > > -- > 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. -- 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.
