I consider this to be a non-issue. There are two ways of writing in a new
language.
- You can learn the language as defined.
- You can write it the way you like it and convert to what is required
and then convert every one else's stuff to what you like. Go makes it
fairly easy for
imo a very important aspect of a language is enduring syntax stability.
Too many 'modern' languages lack even the most fundamental requirement of a
solid Language Specification. Well done Go! And love or hate Java, that's
what made it stable enough for it's massive and enduring success.
Go
Here is the analoguous discussion concerning the ternary operator in Kotlin:
https://discuss.kotlinlang.org/t/ternary-operator/2116
After 168 posts to this thread where the thread creator did not want to
accept that the language needs no ternary operator, the thread was finally
closed by the
Agree with
Mike Schinkel
if IF become functional then useful
else if it is just a syntax change have absolutely no interest
On Thursday, April 25, 2019 at 10:20:54 AM UTC-4, Sam Whited wrote:
>
> On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
> > Are there really developers that find
I disagree with the suggestion.
IF statement indicates a branching of execution path. It should be made to
stand out so that when people are skimming through the code can immediately
pick up these alternate execution paths. Changing it to a mere "?" will
reduce its visibility. You have to
On Wed, Apr 24, 2019 at 8:42 PM David Koblas wrote:
> IMHO I've wanted a switch expression, rather than a switch statement for a
> while.
>
I've wanted that too, but what we already have really isn't that bad.
> value := switch test {
> case true => "red"
> case false => "blue"
> }
>
>
IMHO I've wanted a switch expression, rather than a switch statement for
a while.
value := switch test {
case true => "red"
case false => "blue"
}
or
value := switch item.(type) {
case int => item
case string => strconv.Atoi(item)
case time.Time => {
... something more involved
Wow that was some bad typing + bad auto correct...
> On Apr 24, 2019, at 9:15 PM, Robert Engels wrote:
>
> Your original proposal did not have the colon and also implied the {} were
> mandatory. And what stops the sane syntax from. Ring nested ?
>
>> On Apr 24, 2019, at 6:28 PM,
Your original proposal did not have the colon and also implied the {} were
mandatory. And what stops the sane syntax from. Ring nested ?
> On Apr 24, 2019, at 6:28 PM, lgod...@gmail.com wrote:
>
> Just to clarify : My original proposal was to include as part of Go the
> syntax
>
> (test) ?
I don't think that's an answer to my comment. Was it intended to be?
lgodio wrote that they wanted ternary operators, but were not
advocating that it be possible to allow nested ternary operations. I
don't see how this is possible if you write the grammar as the only
sensible interpretation
switch test {
case true:
//..code block for test=true
case false:
//..code block for test=false
}
On Wed, Apr 24, 2019 at 4:42 PM Dan Kortschak wrote:
> How would you preclude it?
>
> On Wed, 2019-04-24 at 16:28 -0700, lgod...@gmail.com wrote:
> > I am NOT in favor of allowing nested
How would you preclude it?
On Wed, 2019-04-24 at 16:28 -0700, lgod...@gmail.com wrote:
> I am NOT in favor of allowing nested ternary operations
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
Just to clarify : My original proposal was to include as part of Go the
syntax
(test) ? {
{ //..code block for test=true
} : {
//..code block for test=false
}
I am NOT in favor of allowing nested ternary operations
In addition, I also propose allowing un-nested '?' as an alternative
On 24-04-2019, lgod...@gmail.com wrote:
> --=_Part_538_706677508.1556067911841
> Content-Type: multipart/alternative;
> boundary="=_Part_539_1965717614.1556067911841"
>
> --=_Part_539_1965717614.1556067911841
> Content-Type: text/plain; charset="UTF-8"
>
> It sure would be nice
14 matches
Mail list logo
