On Mon, May 13, 2019 at 7:46 AM wrote:
> Given the extent of responses to the original question by the Go community
> (pro and con), hopefully those responsible for Go syntax will re-visit the
> issue and decide whether Go statement "if test then {.. } else { .. }"
> prevents any possible abuse
Dave: Thanks for pursuing this issue and reporting back.
Given the extent of responses to the original question by the Go community
(pro and con), hopefully those responsible for Go syntax will re-visit the
issue and decide whether Go statement "if test then {.. } else { .. }"
prevents any
On May 12, 2019, at 06:55, Jesper Louis Andersen
wrote:
>
> I don't think there are developers who find it unreadable once they know the
> logic of that operator. However, if you don't know the rules, then it looks
> like black magic.
>
> In large software developments, consistency beats
I don't think there are developers who find it unreadable once they know
the logic of that operator. However, if you don't know the rules, then it
looks like black magic.
In large software developments, consistency beats convenience almost all
the time. You can somewhat easily add another
I suggest that we first solve less controversial issues like the
Israeli–Palestinian conflict.
--
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
> As language choice becomes more arbitrary, and transpilers more common,
> personal preferred syntax / language features may end up being handled like
> code formatting rules. So In Peter++ I could then use all the syntax I like,
> transpile that to WASM or LLVM, and someone else working on
Agree completely. Despite my reasoned comfort with Go’s rationale I miss
quite a few “but I want to express this algorithm beautifully for the ages”
features. I don’t miss the ternary syntax but miss the natural way to say
“it is an assignment, first, but subject to logic, second.” Same as I miss
Ada originally followed BCPL and Pascal in distinguishing between commands
(statements) and expressions, compared say to Algol68 which was an
expression language.
BCPL had VALOF/RESULTIS to link the two realms. It also had a conditional
expression (A -> B, C) with the same meaning as B's and
On Wednesday, April 24, 2019 at 2:03:01 PM UTC-7, Kurtis Rader wrote:
>
> On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski > wrote:
>
>> Here's the lore associated with the subject: Ken wanted ternary, Rob
>> and Robert did not. They overruled Ken (remember, early on all three
>> had to agree
The last time there was a big thread about this, I explained how GCC added
“value of brace block is value of last expression” to allow great power,
and a fellow poster explained how this came into being with Algol-68.
There is long history in these ideas, and much value, but Go specifically
chose
I was assuming the compiler did not eliminate it. If it does then my point is
moot.
-Mike
Sent from my iPad
> On Apr 26, 2019, at 9:13 AM, Ian Lance Taylor wrote:
>
>> On Thu, Apr 25, 2019 at 10:57 PM Mike Schinkel wrote:
>>
>> Marcus Low wrote:
>>>
>>> datalen := removedKeyken //
On Thu, Apr 25, 2019 at 10:57 PM Mike Schinkel wrote:
>
> Marcus Low wrote:
>>
>> datalen := removedKeyken // removedKeyken must have been int32 in your
>> example.
>> if value != nil {
>>datalen = len(value)
>> }
>
>
> The issue with this is it makes two assignments when value != nil
> David Riley wrote:
> same potential for abuse (no one is gonna stop you from nesting expressions).
Yes, but only assuming it were implemented as an expression.
However, if it were instead implemented as an “if-assignment" statement?
result := if temperature > 80
then "red"
else
On Apr 26, 2019, at 2:12 AM, Mike Schinkel wrote:
>
> Given that, I am curious what your thoughts would be if this were possible in
> Go instead?
>
>color := if temperature > 80 then “red” else “green”
>
> And especially if this formatting were valid:
>
>color := if temperature >
On Friday, April 26, 2019 at 9:12:06 AM UTC+3, Mike Schinkel wrote:
>
> 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 this unreadable?
>> >
>> > color := temperature >
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 this unreadable?
> >
> > color := temperature > 80 ? “red” : “green”
>
> Yes.
>
> What is "?"? If I've never seen that before
Marcus Low wrote:
>
> datalen := removedKeyken // removedKeyken must have been int32 in your
> example.
> if value != nil {
>datalen = len(value)
> }
>
The issue with this is it makes two assignments when value != nil instead
of just one.
--
You received this message because you are
Please understand that my use of ?: in the proposed grammar is
irrelevant. Using the syntax proposed here leads to the same problem.
You have self contradictory claims below:
1. the change is only a swapping of 'if' => '?' and 'else' => ':' with
no semantic change: "My proposal
The problem is that Go already has if and else and else if (which would look
really weird in your proposal)
Changing a word to a symbol does not enhance meaning - it reduces it, and
increases the learning curve.
Like I said, you will probably like Ada - lots of symbols there.
> On Apr 25,
To Kortschak and all others participating in this debate :
Please don't get hung up over my choice of symbol '?' .
My choice of symbol '?' and ';' is causing people to equate my proposal
with a proposal to adopt C's ternary operator in Go. This is not what I
intended to propose.
My proposal
>
> There are many counter-examples. What is the likelihood that someone who
> is not familiar with the "?" operator will be familiar with the operators
> for getting (*) and dereferencing (&) a pointer. And what is "<-"?
> Certainly people not familiar with Go will initially be confused by
>
The difference is that the ternary operator is an expression and the
if...else is a statement. If you're only suggesting a syntax change,
then the difference becomes one of readability.
I'll ask again, how would you preclude nesting without making the
language more complex?
On Thu, 2019-04-25 at
Rob:
Am I missing something ??
The proposed syntax
test ? {
} : {
}
with no-nesting allowed is equivalent to
if test {
//.
} else {
// ..
}
..The former is just a cleaner way of writing the latter
Any complaints regarding 'abuse' associated with the former equally apply
to the
I'm a big fan of the ternary operator in general. Maybe this is because I'm
an old timey Lisper. A lot of the things people see as "abuse" or "too
complex" are equally problems with || and &&.
This is also true for Jan's point: that ?: affects control flow by omitting
execution sometimes. It
On Thu, Apr 25, 2019 at 8:58 PM wrote:
>
> Rob : how can it be abused if the compiler wont allow nested ? operators ??
Rather easily. Just by fuzzilly mixing the otherwise purposely
distinct syntax of expressions and control flow.
--
You received this message because you are subscribed to the
Rob : how can it be abused if the compiler wont allow nested ? operators ??
On Thursday, April 25, 2019 at 11:47:21 AM UTC-4, Rob 'Commander' Pike
wrote:
>
> I am pretty sure that the decision not to have ?: in Go was a unanimous
> decision by Robert, Ken and myself after almost no discussion.
There are many counter-examples. What is the likelihood that someone who is
not familiar with the "?" operator will be familiar with the operators for
getting (*) and dereferencing (&) a pointer. And what is "<-"? Certainly
people not familiar with Go will initially be confused by operators
I am pretty sure that the decision not to have ?: in Go was a unanimous
decision by Robert, Ken and myself after almost no discussion. It is too
easy to abuse, as the FAQ states.
-rob
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
FYI I recently posted a proposal for some unambiguous syntax which would
give a lot of the value of ternary operators i.e. write the 5 line if-else
block in the FAQ as a 1-liner, without the drawbacks, while IMO preserving
the simplicity of the go language in approachability, readability and
On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
> Are there really developers that find this unreadable?
>
> color := temperature > 80 ? “red” : “green”
Yes.
What is "?"? If I've never seen that before I have no easy way to search
for that, and a random symbol me nothing about what it does.
>
> > Is this so bad?
>
> Yes, it's horrible as you'll loose any type information you had.
> Meaning the next thing you naturally had to do was type cast it, which
> isn't the nicest syntax to begin with.
> By then it's probably more work than just using if / else
>
So what you're saying is that
Go vet doesn’t report on structural issues - and those are far harder to work
with/debug than code with the proper use of ternary operators (or even poor use)
Bad code is bad code no matter how you get there.
On Apr 25, 2019, at 7:05 AM, Lucio wrote:
>>
>> But don't deny others the ability
>
>
> But don't deny others the ability to choose the first alternative
>
That's not what's being denied: what is being denied, is the ability to
write nested ternaries I then have to debug. Fat lot of good it will do me,
that vet reports it to be a misuse.
Lucio.
--
You received this
On Wed, Apr 24, 2019 at 04:24:41PM -0500, Andrew Klager wrote:
> Is this so bad?
Yes, it's horrible as you'll loose any type information you had.
Meaning the next thing you naturally had to do was type cast it, which isn't
the nicest syntax to begin with.
By then it's probably more work than
Please do! We need to resolve this connundrum for the next 5
generations of computer programmers!
On Wed, Apr 24, 2019 at 8:41 PM David Riley wrote:
>
> On Apr 24, 2019, at 5:25 PM, andrey mirtchovski wrote:
> >
> >> I may easily misremember, but that doesn't match my recollection. I
> >>
On Apr 24, 2019, at 5:25 PM, andrey mirtchovski wrote:
>
>> I may easily misremember, but that doesn't match my recollection. I
>> don't remember what position Rob and Robert took, but as I recall Ken
>> was generally opposed to the ternary operator. He had been in part
>> responsible for
Nested ternaries are fairly readable in JavaScript these days due to the
use of Prettier for code formatting.
gofmt could do the same.
For example, this:
lc_unicodeliterals = quote=='u' ? 1 : quote=='U' ? 0 : !!(ast.locale.set &
AST_LC_unicodeliterals);
could be formatted to this:
For me, choosing to write
color = temp < 80 ? { "blue", "red")
vs
func ternary(cond bool, pos, neg interface{}) interface{} {
if cond {
return pos
} else {
return neg
}
}
color := ternary( temp < 80, "blue", "red")
is a no brainer
On Wednesday, April 24, 2019 at 5:25:09 PM
If instead of writing: temperature > 80 ? red : green
you choose to follow Marcus and write instead:
map[bool]string{true:"red",false:"green"}[temperature>80]
OR call
func ternary(x int) int {
return map[bool]int{true:12345,false:-1}[x>0]
}
Go right ahead ! ..as they say, "different
> I may easily misremember, but that doesn't match my recollection. I
> don't remember what position Rob and Robert took, but as I recall Ken
> was generally opposed to the ternary operator. He had been in part
> responsible for adding it to C, and felt that it had been a mistake.
>
> Ian
I am
Is this so bad?
func ternary(cond bool, pos, neg interface{}) interface{} {
if cond {
return pos
} else {
return neg
}
}
color := ternary( temp < 80, "blue", "red")
On Wed, Apr 24, 2019 at 4:14 PM Chris Broadfoot
wrote:
>
>
> On Wed, Apr 24, 2019 at 4:22 AM Robert Engels
> wrote:
>
On Wed, Apr 24, 2019 at 4:22 AM Robert Engels wrote:
> Though to the ops point, not sure why Go doesn’t have the ternary operator
> - which is pretty ubiquitous.
>
https://golang.org/doc/faq#Does_Go_have_a_ternary_form
>
> On Apr 23, 2019, at 9:56 PM, Robert Engels wrote:
>
> Why? You have
On Apr 24, 2019, at 12:34 PM, Marcus Low wrote:
>
> On Wednesday, April 24, 2019 at 10:08:53 PM UTC+8, Mark Volkmann wrote:
>> Are there really developers that find this unreadable?
>>
>> color := temperature > 80 ? “red” : “green”
>>
>> I know what you are going to say. People will nest
On Apr 24, 2019, at 8:04 AM, Mark Volkmann wrote:
>
>
>> On Apr 24, 2019, at 6:22 AM, Robert Engels wrote:
>>
>> Though to the ops point, not sure why Go doesn’t have the ternary operator -
>> which is pretty ubiquitous.
>
> The idea of adding the ternary operator to Go has been debated
On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski
wrote:
>
> Here's the lore associated with the subject: Ken wanted ternary, Rob
> and Robert did not. They overruled Ken (remember, early on all three
> had to agree for a feature to go in). The end.
I may easily misremember, but that doesn't
On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski
wrote:
> Here's the lore associated with the subject: Ken wanted ternary, Rob
> and Robert did not. They overruled Ken (remember, early on all three
> had to agree for a feature to go in). The end.
>
> The number of frivolous and egregious abuse
Here's the lore associated with the subject: Ken wanted ternary, Rob
and Robert did not. They overruled Ken (remember, early on all three
had to agree for a feature to go in). The end.
The number of frivolous and egregious abuse of ternary that I've seen
in _modern_ C code is too high.jpg
--
I agree, and I think the ternary represents the logic much cleaner than if/else
in this case. This would be especially true if you could do:
final datalen := value==nil ? removedKeyken : len(value)
> On Apr 24, 2019, at 1:18 PM, Mark Volkmann wrote:
>
> I'm at a loss as to how that could be
I'm at a loss as to how that could be considered more readable that a
single ternary.
You've successfully changed five lines to four lines, but that's still a
long way from one line.
On Wed, Apr 24, 2019 at 12:15 PM Marcus Low wrote:
> Yeah of course I was joking... the solution I provided does
Yeah of course I was joking... the solution I provided does work for the "I
need a one-liner" mentality, though.
I believe this following solution fits your use case, and is simpler to
read too:
datalen := removedKeyken // removedKeyken must have been int32 in your
example.
if value != nil {
I’m pretty sure you’re joking... but I think most are referring to simple
usages, like this (from my own code). Clearly, there are others was of
designing it to avoid the usage, but sometimes what is simple really is
simpler.
var datalen int32
if value == nil {
datalen = removedKeyken
}
color := map[bool]string{true:"red",false:"green"}[temperature>80]
Here you go.
On Wednesday, April 24, 2019 at 10:08:53 PM UTC+8, Mark Volkmann wrote:
>
> Are there really developers that find this unreadable?
>
> color := temperature > 80 ? “red” : “green”
>
> I know what you are going to
I personally do not find ternary operators to be readable in any form.
For those who are truly desperate for that cosmetic one-line kick, though,
here's an example you can use (which looks just about as unreadable as any
ternary operator out there):
// ternary returns 12345 if x is positive (x
Yes, but the FAQ has similar concerns about readability and maintainability as
reasons for not having generics, but adds the language “may change”... not sure
that is consistent with the views on the tenant operator.
> On Apr 24, 2019, at 9:52 AM, Ian Lance Taylor wrote:
>
> The lack of the
The lack of the ?: operator in Go is a FAQ:
https://golang.org/doc/faq#Does_Go_have_a_ternary_form .
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
Are there really developers that find this unreadable?
color := temperature > 80 ? “red” : “green”
I know what you are going to say. People will nest them. But even nested usage
can be readable when formatted nicely with one condition per line. Another
alternative is to allow only unnested
On Wed, Apr 24, 2019 at 3:48 PM L Godioleskky wrote:
>
> The lack of a Go ternary operator is at odds with Go's major theme of clean
> and easy to read syntax. Those who choose not to use the ternary operator can
> always resort back to Go's current 'if -else' or 'case' syntax. So Go syntax
>
The lack of a Go ternary operator is at odds with Go's major theme of clean
and easy to read syntax. Those who choose not to use the ternary operator
can always resort back to Go's current 'if -else' or 'case' syntax. So Go
syntax suffers no negative impact by adding the ternary op to its syntax
That’s not what he meant. It takes 5 lines for a trivial assignment if/else
rather than 1 line with a ternary with no loss in readability.
> On Apr 24, 2019, at 7:11 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Wed, Apr 24, 2019 at 2:04 PM Mark Volkmann
>> wrote:
>>
>> The idea of adding
On Wed, Apr 24, 2019 at 2:04 PM Mark Volkmann wrote:
> The idea of adding the ternary operator to Go has been debated many times.
> It’s clear that those in charge have a strong dislike for it. For me the lack
> of the ternary operator is one of main things I dislike about Go. It’s nails
> on
> On Apr 24, 2019, at 6:22 AM, Robert Engels wrote:
>
> Though to the ops point, not sure why Go doesn’t have the ternary operator -
> which is pretty ubiquitous.
The idea of adding the ternary operator to Go has been debated many times. It’s
clear that those in charge have a strong
Though to the ops point, not sure why Go doesn’t have the ternary operator -
which is pretty ubiquitous.
> On Apr 23, 2019, at 9:56 PM, Robert Engels wrote:
>
> Why? You have saved 5 characters for no practical gain. I think you would
> enjoy Ada.
>
>> On Apr 23, 2019, at 8:05 PM,
On Wed, Apr 24, 2019 at 3:05 AM wrote:
>
> It sure would be nice if Go syntax allowed programmers to replace
>
> if ( test) {
> ...do sonething
> }
That's not how Go's if statement looks. Gofmt will remove the
superficial parentheses around 'test'.
Wrt the rest of the proposal, today, this is
Why? You have saved 5 characters for no practical gain. I think you would enjoy
Ada.
> On Apr 23, 2019, at 8:05 PM, lgod...@gmail.com wrote:
>
> It sure would be nice if Go syntax allowed programmers to replace
>
> if ( test) {
> ...do sonething
> } else {
> ..do something else
> }
>
> with
> ? (test) {
> //...do something
> }
> {
> //..do something else
> }
I believe the Go team considered this very carefully early on the
language's development and came to the decision to use "if test" for
"? (test)" and "} else {" for "}{" (without the implied newline). They
also threw in "} else
It sure would be nice if Go syntax allowed programmers to replace
if ( test) {
...do sonething
} else {
..do something else
}
with
? (test) {
//...do something
}
{
//..do something else
}
The ? operator can be anything the Go language team considers appropriate
--
You received this message
66 matches
Mail list logo
