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.wagner...@googlemail.com>
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 <michael.jo...@gmail.com>
> 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.christian...@gmail.com> 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+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.
>>
>
>
--
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.
