The spec <https://golang.org/ref/spec#Keywords> says 'keyword' are
"reserved and may not be used as identifiers", so adding any new keyword
would necessarily break existing programs which use that keyword as an
identifier, regardless of restrictions on the keyword's use. Perhaps you
mean a less restricted class of 'reserved word' (for example: like 'iota
and 'nil')? But 'for' is a keyword, so adding 'do' or 'while' as anything
other than a keyword seems unappealing and suspect, even if technically
possible.
On Sunday, March 5, 2017 at 1:07:35 AM UTC-6, Michael Jones wrote:
> Minor follow up along those lines: i think we *could* add a new keyword or
> form (for any purpose), it just needs to be one that does not break
> existing programs.
>
> as an example
>
> x := 12345.12345
> a := int(x)
>
> could be elaborated as
>
> x := 12345.12345 rounded 27 //bits of mantissa
>
> or
>
> a := int(x, 27) // bits of mantissa
>
> which are changes that break nothing. They are also not proposal...just
> saying that a new keyword like 'rounded' that goes after a <<numeric
> value>> would not conflict (i think...just winging it here) and neither
> would new additional arguments in a cast.
>
> So yes, new is not impossible. The alias mechanism found a way to inert
> new meanings in a way that did not change existing valid programs.
>
> The "{...}for <<condition>>" is also an issue since either the loop can
> have no local control variables or else the body of the "{...}" uses them
> before they are defined at the bottom. This is not nice.
>
> Maybe for Go 2 we could lobby for:
>
> for <<a;b;c>> {
> <<body>>
> } while <<d>>
>
> which would compile as:
>
> {
> <<a>>
> TOP:
> if !<<b>> goto DONE
> <<body>>
> if !<<d>> goto DONE
> <<c>>
> goto TOP
> DONE:
> }
>
>
>
>
> On Sat, Mar 4, 2017 at 10:32 AM, Axel Wagner <axel.wa...@googlemail.com
> <javascript:>> wrote:
>
>> There would be a way to add them without adding a new keyword:
>>
>> {
>> // stuff
>> } for condition
>>
>> I'm not saying I want it, or that it's a good idea, just that "we can't
>> add a new keyword" doesn't seem a good argument for not doing it. At least
>> at a cursory glance I don't see why we'd need the do keyword.
>>
>> On Sat, Mar 4, 2017 at 1:21 AM, Michael Jones <michae...@gmail.com
>> <javascript:>> wrote:
>>
>>> I asked for this early...long before it was too late. (Existing valid
>>> programs ma have variables named 'do' so it is a non starter in that form.
>>>
>>> Rob's objection was wise and thoughtful. He wanted Go to be friendly to
>>> program transformation and he felt that a single uniform iteration
>>> construct would be "more better" for that than the workarounds you have
>>> been shown would be "more bad" stylistically.
>>>
>>> I did not get what I asked for, but I did get an education about careful
>>> trade offs.
>>>
>>> On Sat, Mar 4, 2017 at 12:06 AM <milo.chr...@gmail.com <javascript:>>
>>> wrote:
>>>
>>>> It's not really, it is just syntactic sugar. I just happen to think
>>>> that this kind of loop is common enough to have dedicated syntax. Not
>>>> necessarily the syntax I used in my example (that has its issues), but
>>>> something similar.
>>>>
>>>> Your example it is how I do it myself currently :)
>>>>
>>>>
>>>> On Friday, March 3, 2017 at 6:00:46 PM UTC-5, peterGo wrote:
>>>>>
>>>>> milo,
>>>>>
>>>>> How is your loop different from this?
>>>>>
>>>>> for {
>>>>> // <loop body actions>
>>>>> if condition {
>>>>> break
>>>>> }
>>>>> }
>>>>>
>>>>> Peter
>>>>>
>>>>> On Friday, March 3, 2017 at 5:00:41 PM UTC-5, milo.chr...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> I rather like Go's loops, they are simple and easy to remember, and
>>>>>> the problem so many languages have with dozens of different loop
>>>>>> keywords
>>>>>> is neatly avoided. Too many loop types is simply a pain, but I think
>>>>>> that
>>>>>> one more wouldn't hurt...
>>>>>>
>>>>>> Basically the following would be helpful in some cases without being
>>>>>> too "odd" compared to what is existing:
>>>>>>
>>>>>> do{
>>>>>> // <loop body actions>
>>>>>> }for condition
>>>>>>
>>>>>> Is this a good idea? Why or why not? Anyone else have a better idea
>>>>>> for the syntax? (depending on how you look at it either "do" or "for" is
>>>>>> redundant, but removing "do" would probably require too much lookahead)
>>>>>>
>>>>> --
>>>> 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...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> Michael T. Jones
>>> michae...@gmail.com <javascript:>
>>>
>>> --
>>> 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...@googlegroups.com <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
>
> --
> Michael T. Jones
> michae...@gmail.com <javascript:>
>
--
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.
