Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

[Thorsten Seitz via swift-evolution]

+1 to Jon's answer.
-1 to the proposal. I have argued in the past for introducing an if-then-else 
expression instead of the ternary operator but I wouldn't replace it with a 
clunky function which reduces readability a lot IMHO.

-Thorsten 

> Am 26.10.2016 um 19:57 schrieb Jon Akhtar via swift-evolution 
> <swift-evolution@swift.org>:
> 
> I think that we need to get past the “leftovers from C” being a bad thing 
> mindset. Familiar constructs make Swift easier for programmers (its target 
> audience) easier to learn.
> 
> Point by point:
> 
> Being a holdover from C isn’t a bad thing. We can take things that were 
> useful in C and make them part of Swift. Who said C language elements were a 
> non-goal of Swift. And to the “ternary operator is hard to learn” point. This 
> point gets made over and over in proposals to change Swift, ease of learning 
> is like performance and security – you can never have enough so there is no 
> counter-argument. If you can’t learn the ternary operator, Swift isn’t the 
> language for you, because what are you going to do when you get to generics 
> and higher order functions.
> If the ternary operator adds complexity to the compiler then it really isn’t 
> a holdover from C. We have quite a long time to know how to parse it from our 
> C legacy.
> See #1, new users are always confused about everything. They don’t stay that 
> way. The language doesn’t need to be tuned to support it’s non-users. Most 
> developers understand the ternary operator, and it is useful to them. Who is 
> this language for?
> The “:” appears in other places in the grammar. So what. So do parenthesis 
> and brackets. It is just a token used in a grammar rule as a separator, it 
> doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its 
> function.
> So your argument is to make the ternary expression longer to discourage 
> nesting. This is much different than the argument for function(a++, ++a) 
> where order of function parameter evaluation influenced the code, but was not 
> expressed by it. Everything is fully expressed by the ternary operator 
> including order of evaluation.
> I see no problem with it being limited to bool. I don’t want Javascript’s “” 
> == false.
> What would be proposed (and has been) is the if expression which is more 
> verbose but easier to read
> Again, the C hate.
> You leave out the reason for those languages to leave out the ternary 
> operator. What was their rationale?
> I’m sorry you had a hard time with it. But you learned it, and now you can 
> apply that knowledge to any language that has it. To add to the anecdotal 
> evidence you provided, I did not have a hard time learning it.
> I can distill this down to “C is old and not modern so lets get rid of 
> anything from C” and “I had a hard time learning the ternary operator"
> 
> Bottom line, most developers know the ternary expression if they come from C, 
> C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different 
> for style reasons. We will be making a niche language, because what you learn 
> isn’t portable to another language like it is if you learn Java, then get a 
> job programming in C#.
> 
> 
> 
> From: <swift-evolution-boun...@swift.org> on behalf of Mark Sands via 
> swift-evolution <swift-evolution@swift.org>
> Reply-To: Mark Sands <marksand...@gmail.com>
> Date: Wednesday, October 26, 2016 at 09:55
> To: William Sumner <prestonsum...@me.com>
> Cc: Swift-Evolution <swift-evolution@swift.org>
> Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary 
> operator with an in-language function
> 
> 
> 
>> Training users to expect source-breaking churn would be highly damaging to 
>> the language. The removal of C-style for loops and increment/decrement 
>> operators came with sufficient justification beyond their being inherited 
>> from C. I don’t think there’s a sufficient justification for this change, 
>> especially with the bar set high for such changes. 
>> 
>> Preston
> 
> My apologies for skewing the conversation off-topic. I think what I meant to 
> imply is that we shouldn't be afraid of a deprecation warning. Migrating away 
> from a ternary operator is trivial, and the consequences usually come with 
> better readability.
> 
> Ignoring my statement about "leftovers from C" opposition, I do think there 
> is sufficient and very strong justification from the 10 items that Charlotte 
> has listed. I think it would be more valuable if one could pick apart each 
> bullet point they find excusable and list their reasons why it's not 
> compelling enough to warrant change.
> + V2 Checkin API
> + V2 Checkout API
&g

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

[Chris Lattner via swift-evolution]

On Oct 26, 2016, at 11:54 AM, Haravikk via swift-evolution 
 wrote:
>> 
>> Bottom line, most developers know the ternary expression if they come from 
>> C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be 
>> different for style reasons. We will be making a niche language, because 
>> what you learn isn’t portable to another language like it is if you learn 
>> Java, then get a job programming in C#.
> 
> While I agree on most of this, I think there is reasonable justification to 
> discuss this on the basis of it using the question-mark; Swift uses the 
> question mark extensively for handling of optionals, so there is an element 
> of confusion present there, it also uses the colon in a somewhat unfamiliar 
> way as well, so it's a twofold oddity in Swift.
> 
> That said, I'm not sure replacing it with a function is superior; this is 
> something you can do yourself easily enough if you feel you need to, and 
> which learners can likewise do if they don't know about, or don't like the 
> operator.
> 
> So the question really is whether there's an alternative that is similarly 
> concise, and on that I'm not so sure, so I'd lean towards leaving it as it 
> is, but advising people to be careful about where they use it, as its very 
> advantage in size can be a disadvantage in readability, so it should be used 
> with care at all times.

I’ll add a couple of more points:

1. This was extensively discussed in the Swift 3 release cycle, in multiple 
threads, and never went anywhere.
2. Changing this in Swift 4 is extremely unlikely even if there is a good 
answer, because - unlike in Swift 3 timeframe - any change that breaks source 
code needs extreme justification of why it is the right long term thing to do.  
I can’t fathom a rationale for this in the case of the ?: operator.  Merely 
being potentially confusing is not enough.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

[Haravikk via swift-evolution]

> On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution 
>  wrote:
> 
> I think that we need to get past the “leftovers from C” being a bad thing 
> mindset. Familiar constructs make Swift easier for programmers (its target 
> audience) easier to learn.
> 
> Point by point:
> 
> Being a holdover from C isn’t a bad thing. We can take things that were 
> useful in C and make them part of Swift. Who said C language elements were a 
> non-goal of Swift. And to the “ternary operator is hard to learn” point. This 
> point gets made over and over in proposals to change Swift, ease of learning 
> is like performance and security – you can never have enough so there is no 
> counter-argument. If you can’t learn the ternary operator, Swift isn’t the 
> language for you, because what are you going to do when you get to generics 
> and higher order functions.
> If the ternary operator adds complexity to the compiler then it really isn’t 
> a holdover from C. We have quite a long time to know how to parse it from our 
> C legacy.
> See #1, new users are always confused about everything. They don’t stay that 
> way. The language doesn’t need to be tuned to support it’s non-users. Most 
> developers understand the ternary operator, and it is useful to them. Who is 
> this language for?
> The “:” appears in other places in the grammar. So what. So do parenthesis 
> and brackets. It is just a token used in a grammar rule as a separator, it 
> doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its 
> function.
> So your argument is to make the ternary expression longer to discourage 
> nesting. This is much different than the argument for function(a++, ++a) 
> where order of function parameter evaluation influenced the code, but was not 
> expressed by it. Everything is fully expressed by the ternary operator 
> including order of evaluation.
> I see no problem with it being limited to bool. I don’t want Javascript’s “” 
> == false.
> What would be proposed (and has been) is the if expression which is more 
> verbose but easier to read
> Again, the C hate.
> You leave out the reason for those languages to leave out the ternary 
> operator. What was their rationale?
> I’m sorry you had a hard time with it. But you learned it, and now you can 
> apply that knowledge to any language that has it. To add to the anecdotal 
> evidence you provided, I did not have a hard time learning it.
> I can distill this down to “C is old and not modern so lets get rid of 
> anything from C” and “I had a hard time learning the ternary operator"
> 
> Bottom line, most developers know the ternary expression if they come from C, 
> C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different 
> for style reasons. We will be making a niche language, because what you learn 
> isn’t portable to another language like it is if you learn Java, then get a 
> job programming in C#.

While I agree on most of this, I think there is reasonable justification to 
discuss this on the basis of it using the question-mark; Swift uses the 
question mark extensively for handling of optionals, so there is an element of 
confusion present there, it also uses the colon in a somewhat unfamiliar way as 
well, so it's a twofold oddity in Swift.

That said, I'm not sure replacing it with a function is superior; this is 
something you can do yourself easily enough if you feel you need to, and which 
learners can likewise do if they don't know about, or don't like the operator.

So the question really is whether there's an alternative that is similarly 
concise, and on that I'm not so sure, so I'd lean towards leaving it as it is, 
but advising people to be careful about where they use it, as its very 
advantage in size can be a disadvantage in readability, so it should be used 
with care at all times.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

[Goffredo Marocchi via swift-evolution]

Very well said, thanks :)!

Sent from my iPhone

> On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I think that we need to get past the “leftovers from C” being a bad thing 
> mindset. Familiar constructs make Swift easier for programmers (its target 
> audience) easier to learn.
> 
> Point by point:
> 
> Being a holdover from C isn’t a bad thing. We can take things that were 
> useful in C and make them part of Swift. Who said C language elements were a 
> non-goal of Swift. And to the “ternary operator is hard to learn” point. This 
> point gets made over and over in proposals to change Swift, ease of learning 
> is like performance and security – you can never have enough so there is no 
> counter-argument. If you can’t learn the ternary operator, Swift isn’t the 
> language for you, because what are you going to do when you get to generics 
> and higher order functions.
> If the ternary operator adds complexity to the compiler then it really isn’t 
> a holdover from C. We have quite a long time to know how to parse it from our 
> C legacy.
> See #1, new users are always confused about everything. They don’t stay that 
> way. The language doesn’t need to be tuned to support it’s non-users. Most 
> developers understand the ternary operator, and it is useful to them. Who is 
> this language for?
> The “:” appears in other places in the grammar. So what. So do parenthesis 
> and brackets. It is just a token used in a grammar rule as a separator, it 
> doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its 
> function.
> So your argument is to make the ternary expression longer to discourage 
> nesting. This is much different than the argument for function(a++, ++a) 
> where order of function parameter evaluation influenced the code, but was not 
> expressed by it. Everything is fully expressed by the ternary operator 
> including order of evaluation.
> I see no problem with it being limited to bool. I don’t want Javascript’s “” 
> == false.
> What would be proposed (and has been) is the if expression which is more 
> verbose but easier to read
> Again, the C hate.
> You leave out the reason for those languages to leave out the ternary 
> operator. What was their rationale?
> I’m sorry you had a hard time with it. But you learned it, and now you can 
> apply that knowledge to any language that has it. To add to the anecdotal 
> evidence you provided, I did not have a hard time learning it.
> I can distill this down to “C is old and not modern so lets get rid of 
> anything from C” and “I had a hard time learning the ternary operator"
> 
> Bottom line, most developers know the ternary expression if they come from C, 
> C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different 
> for style reasons. We will be making a niche language, because what you learn 
> isn’t portable to another language like it is if you learn Java, then get a 
> job programming in C#.
> 
> 
> 
> From: <swift-evolution-boun...@swift.org> on behalf of Mark Sands via 
> swift-evolution <swift-evolution@swift.org>
> Reply-To: Mark Sands <marksand...@gmail.com>
> Date: Wednesday, October 26, 2016 at 09:55
> To: William Sumner <prestonsum...@me.com>
> Cc: Swift-Evolution <swift-evolution@swift.org>
> Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary 
> operator with an in-language function
> 
> 
> 
>> Training users to expect source-breaking churn would be highly damaging to 
>> the language. The removal of C-style for loops and increment/decrement 
>> operators came with sufficient justification beyond their being inherited 
>> from C. I don’t think there’s a sufficient justification for this change, 
>> especially with the bar set high for such changes. 
>> 
>> Preston
> 
> My apologies for skewing the conversation off-topic. I think what I meant to 
> imply is that we shouldn't be afraid of a deprecation warning. Migrating away 
> from a ternary operator is trivial, and the consequences usually come with 
> better readability.
> 
> Ignoring my statement about "leftovers from C" opposition, I do think there 
> is sufficient and very strong justification from the 10 items that Charlotte 
> has listed. I think it would be more valuable if one could pick apart each 
> bullet point they find excusable and list their reasons why it's not 
> compelling enough to warrant change.
> + V2 Checkin API
> + V2 Checkout API
> + V2 Get Admission Records [Updated]
> + V2 Get Scan Records
> - New SQLite Data File generation
> - V2 Get User Events
> - V2 Scan Record Submission
> 
> - GDO Ticket Pur

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

[Jon Akhtar via swift-evolution]

I think that we need to get past the “leftovers from C” being a bad thing 
mindset. Familiar constructs make Swift easier for programmers (its target 
audience) easier to learn.

Point by point:


  1.  Being a holdover from C isn’t a bad thing. We can take things that were 
useful in C and make them part of Swift. Who said C language elements were a 
non-goal of Swift. And to the “ternary operator is hard to learn” point. This 
point gets made over and over in proposals to change Swift, ease of learning is 
like performance and security – you can never have enough so there is no 
counter-argument. If you can’t learn the ternary operator, Swift isn’t the 
language for you, because what are you going to do when you get to generics and 
higher order functions.
  2.  If the ternary operator adds complexity to the compiler then it really 
isn’t a holdover from C. We have quite a long time to know how to parse it from 
our C legacy.
  3.  See #1, new users are always confused about everything. They don’t stay 
that way. The language doesn’t need to be tuned to support it’s non-users. Most 
developers understand the ternary operator, and it is useful to them. Who is 
this language for?
  4.  The “:” appears in other places in the grammar. So what. So do 
parenthesis and brackets. It is just a token used in a grammar rule as a 
separator, it doesn’t have a meaning on its own, and it shouldn’t have one that 
isn’t its function.
  5.  So your argument is to make the ternary expression longer to discourage 
nesting. This is much different than the argument for function(a++, ++a) where 
order of function parameter evaluation influenced the code, but was not 
expressed by it. Everything is fully expressed by the ternary operator 
including order of evaluation.
  6.  I see no problem with it being limited to bool. I don’t want Javascript’s 
“” == false.
  7.  What would be proposed (and has been) is the if expression which is more 
verbose but easier to read
  8.  Again, the C hate.
  9.  You leave out the reason for those languages to leave out the ternary 
operator. What was their rationale?
  10. I’m sorry you had a hard time with it. But you learned it, and now you 
can apply that knowledge to any language that has it. To add to the anecdotal 
evidence you provided, I did not have a hard time learning it.

I can distill this down to “C is old and not modern so lets get rid of anything 
from C” and “I had a hard time learning the ternary operator"

Bottom line, most developers know the ternary expression if they come from C, 
C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different 
for style reasons. We will be making a niche language, because what you learn 
isn’t portable to another language like it is if you learn Java, then get a job 
programming in C#.



From: 
<swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
on behalf of Mark Sands via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Reply-To: Mark Sands <marksand...@gmail.com<mailto:marksand...@gmail.com>>
Date: Wednesday, October 26, 2016 at 09:55
To: William Sumner <prestonsum...@me.com<mailto:prestonsum...@me.com>>
Cc: Swift-Evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary operator 
with an in-language function



Training users to expect source-breaking churn would be highly damaging to the 
language. The removal of C-style for loops and increment/decrement operators 
came with sufficient justification beyond their being inherited from C. I don’t 
think there’s a sufficient justification for this change, especially with the 
bar set high for such changes.

Preston

My apologies for skewing the conversation off-topic. I think what I meant to 
imply is that we shouldn't be afraid of a deprecation warning. Migrating away 
from a ternary operator is trivial, and the consequences usually come with 
better readability.

Ignoring my statement about "leftovers from C" opposition, I do think there is 
sufficient and very strong justification from the 10 items that Charlotte has 
listed. I think it would be more valuable if one could pick apart each bullet 
point they find excusable and list their reasons why it's not compelling enough 
to warrant change.
+ V2 Checkin API
+ V2 Checkout API
+ V2 Get Admission Records [Updated]
+ V2 Get Scan Records
- New SQLite Data File generation
- V2 Get User Events
- V2 Scan Record Submission

- GDO Ticket Purchase Integration API

- V2 Get Ticket Record(s) [New]
- V2 Ticket Creation API [Updated]
- V2 Ticket Info API [New]
- V2 Ticket Transfer API [New]
- V2 Ticket Re-issue API [New]
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution