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] [Pitch] Replace the ternary operator with an in-language function

[Jay Abbott via swift-evolution]

David, you can use two binary operators (or overload the same one twice if
you want) to create syntax that behaves like a ternary operator.

Here’s an example of using a pair of operators to interpolate between two
CGPoint values:

let interpolatedPoint = p1 <~~ 0.3 ~~> p2

See here

for the code that defines them.

I went for two different operators in the end, but when experimenting I
also tried using the same one, and it works fine because of overloading,
for example:

infix operator ~~> : InterpolationPrecedence
public func ~~> (from: T, alpha: Double) -> (T, Double) {
return (from, alpha)
}
public func ~~> (lhs: (T, Double), rhs: T) -> T {
return lerp(from: lhs.0, to: rhs, alpha: lhs.1)
}let interpolatedPoint = p1 ~~> 0.3 ~~> p2

And as Anton demonstrated earlier, ?: can be emulated the same way. The
errors you would get if you omitted the second operator and third part are
not as useful as they can be with ?:. The compiler can probably do a much
better job of optimising with ?: as a special case, and it’s a common
pattern regardless of syntax, so people would just write their own if it
wasn’t there. So I think it makes sense to have it in the language. And if
it wasn’t already there, I do think that it would be something we should
add (same for ??).
​

On Thu, 27 Oct 2016 at 01:44 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 25, 2016, at 23:51, Charlotte Angela Tortorella via swift-evolution
>  wrote:
>
> Disadvantages of The Ternary Operator
> 
>
> [...]
>
>
> 6. This operator is only applicable to a single type, `Bool`.
>
> [...]
>
>
> Proposed Approach
> 
>
> We should drop the ternary operator in favor of a new extension to `Bool`.
>
>
> I'm not sure proposals should do exactly what they claim is a downside of
> the current approach. Especially when the downside in question is
> inherent to the problem being solved.
>
> FWIW, the only thing I find confusing about the ternary operator is that I
> can't overload it. Being able to define my own ternary operators would be
> great, but I don't have an answer to obvious potential ambiguities.
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Expanded type category constraints

[Russ Bishop via swift-evolution]

Do we already have a proposal for expanding constraints to support categories 
beyond class? I am guessing this might have ABI stability concerns, or at least 
library resilience concerns.

If so and no one else has tackled it I’m happy to write up a proposal. There 
are only a couple that I know of:

valuetype
Only struct and enum types would satisfy this constraint.

valuetype(pure)
A struct or enum that contain no reference types at all. The only reason to add 
this would be allowing certain optimizations, though the way existentials work 
today I’m not sure if this is even possible because the calls to value 
witnesses need to be emitted anyway.

functiontype
A function type. This doesn’t have much use today but eventually we could 
expand this to support reflecting the number and type of arguments, dynamically 
invoking, etc.



If there aren’t any ABI or resilience concerns then we can shelve it. I created 
https://bugs.swift.org/browse/SR-3056  
to track the idea in either case.

Russ


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

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

[David Sweeris via swift-evolution]

> On Oct 25, 2016, at 23:51, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> Disadvantages of The Ternary Operator
> 
> [...]
> 
> 6. This operator is only applicable to a single type, `Bool`.
> 
> [...]
> 
> Proposed Approach
> 
> We should drop the ternary operator in favor of a new extension to `Bool`.

I'm not sure proposals should do exactly what they claim is a downside of the 
current approach. Especially when the downside in question is inherent to the 
problem being solved.

FWIW, the only thing I find confusing about the ternary operator is that I 
can't overload it. Being able to define my own ternary operators would be 
great, but I don't have an answer to obvious potential ambiguities.

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Matt Whiteside via swift-evolution]

> On Oct 24, 2016, at 22:33, Chris Lattner via swift-evolution 
>  wrote:
> would it be possible to carve off some obvious blocks of emoji support as 
> identifiers (e.g. not symbols, flags, or anything else complicated), and 
> carve off the most obvious blocks of the math operators as operators?  For 
> the operator set, maybe we could start with some small subset of 100 (totally 
> random number here) operators that are commonly requested and seem obvious, 
> then expand it out to a principled set once UAX31 is resolved?  

+1 to this approach. 

Regarding emoji, I don’t really use them much myself, so I’m favor of the 
minimal amount of work needed to get them under control (for now).  I’d rather 
see the effort spent elsewhere.  The operator stuff is interesting though.

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

Re: [swift-evolution] guard let x = x

[David Goodine via swift-evolution]

First off, Chris made it clear dealing with this isn't a priority for Swift 4 
so take my comments (inline below) with a grain of salt. At least for the time 
being this horse should Rest In Peace. 

> On Oct 26, 2016, at 11:58 AM, Erica Sadun  wrote:
> 
> 
>> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution 
>>  wrote:
>> 
>> Hey all,
>> 
>> As usual, apologies if this horse was beaten ages ago before I joined the 
>> mailing list, but thought I would bring this up.
>> 
>> I was typing the above (for the hundredth time) the other day and I was 
>> wondering whether it might be worth considering offering a shorter syntax:
>> 
>> guard let x, y, z else {…}
>> 
>> I was never convinced why implicit nil checks (i.e. if x {…}) were such a 
>> bad thing.  But now in Swift it seems that it would be much more convenient 
>> to be able to simply skip the assignment part of the expression and define 
>> the above as guaranteeing and unwrapping x, y and z in the appropriate scope.
>> 
>> I think with such powerful and already compact expressions now wanting to 
>> get on the same line,adding this would make the language even more compact 
>> and elegant.  It could be added as a non-source-breaking change, still 
>> allowing x = x for those who prefer it, but could significantly tighten up 
>> such uses, which I’m finding are ubiquitous in my code.
>> 
>> Any thoughts?
>> 
>> -d
> 
> There are safety arguments to be made for introducing a way to bind an 
> optional to a shadowed variable that is guaranteed to be the same name 
> ensuring the conditionally bound item does not accidentally shadow any other 
> item. 
> 

Chris also raised this in a comment in this thread, and I agree with Swift's 
philosophy that terseness shouldn't compromise clarity of intent. 

What I don't get is why 'let x = x' is any clearer than the alternative I 
suggested. It's intent is only clear because the language defines it as such. 
In fact, I would argue that to programmers familiar with most other popular 
languages, it's intuitively unclear, even meaningless (except for being a rare 
reference to a 1980s Laurie Anderson song). 

I was simply suggesting that since neither is a familiar syntax, Swift could 
simple "define it as such" in a more compact (and as Chris pointed out, more 
DRY form).

That said, I do like your earlier proposal to introduce the 'bind' form (and 
agree with Chris that 'unwrap' would be clearer). Perhaps that's the way to go 
when it's time to tackle the issue. 

-d

(p.s. I'm still secretly trying to work a reference to the Dead Parrot sketch 
to issues like these. Perhaps one day...)

> Your initial suggestion doesn't work as overloading "let" confuses rather 
> than clarifies this process. In February, I brought up `bind x` to mean 
> "conditionally bind x to x, and produce a conditional fail if that's not 
> possible", with the hope that "bind self" could be used in closures. Under 
> that scheme your example would read:
> 
> guard bind x, bind y, bind z else { ... }
> 
> "The bind thread" was discussed during the first week of February 2016. Joe 
> Groff had said: "If you all are serious about this, I think you should start 
> a new thread about it."  I thought it was worth a serious discussion just so 
> it could be evaluated and either adopted or discarded and dropped forever. 
> The arguments for:
> 
> * Simplifying an mildly complex and potentially misleading statement 
> * Creating a deliberate and controlled rather than accidental shadowing style
> 
> The discussion petered out, with Kevin Ballard making the strongest case 
> against: "If your goal here is to just avoid having to write the `= foo`, 
> then I disagree with the whole motive. If your goal here is to just use a 
> keyword `bind` instead of `let` (e.g. if you want to use `if bind foo = foo { 
> ... }`), I still disagree, because this new keyword serves no purpose. `if 
> let foo = bar { ... }` is not "fundamentally different" than `let foo = bar`, 
> it's still binding a new identifier to a value, the only difference is it 
> binds it to an optional value. And it's really just a specialization of `if 
> case let foo? = bar { ... }`. I've asked in the past about whether it's worth 
> keeping the special case around now that we have `if case let` (or more 
> specifically, if we should just turn `if let` into the generalized version, 
> so you'd say `if let foo? = bar {... }`) and the answer from the core team 
> was that they already tried it internally and found that the usage of 
> optionals was so prevalent that the special-case optional-specific form of 
> `if let` was worth keeping."
> 
> There was not sufficient support to push forward with this, and reasonable 
> arguments against. I'd suggest the long since beaten horse has moved on to a 
> better world.
> 
> -- E
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org

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 
>  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:  on behalf of Mark Sands via 
> swift-evolution 
> Reply-To: Mark Sands 
> Date: Wednesday, October 26, 2016 at 09:55
> To: William Sumner 
> Cc: Swift-Evolution 
> 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
> 

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: 
> 
on behalf of Mark Sands via swift-evolution 
>
Reply-To: Mark Sands >
Date: Wednesday, October 26, 2016 at 09:55
To: William Sumner >
Cc: Swift-Evolution 
>
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

Re: [swift-evolution] guard let x = x

[Chris Lattner via swift-evolution]

> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado  
> wrote:
> 
> In your example the keyword only makes sense if you are shadowing the 
> optional variable. How would unwrap work with a different name?

It wouldn’t: “unwrap” would never include an equal sign.  If you want to do 
that, use a standard "if let”.

-Chris

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

Re: [swift-evolution] guard let x = x

[Joshua Alvarado via swift-evolution]

In your example the keyword only makes sense if you are shadowing the
optional variable. How would unwrap work with a different name?

Ex:
guard let bar = foo else {...}
guard unwrap bar else {...} -> There is no context to what the guard is
unwrapping
This could end up leading to:
guard unwrap bar = foo else {...} which is essentially the same as the
current guard

Alvarado, Joshua

On Wed, Oct 26, 2016 at 11:09 AM, Josh Parmenter via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> To me, this is the most promising direction, but I’d suggest the use of
> “unwrap" as the keyword.  If you compare these two:
>
> a) guard let foobar = foobar else { … }
> b) guard unwrap foobar else { … }
>
> I think that b) wins by virtue of eliminating repetition ("foobar =
> foobar" fails DRY principles), but retains clarity by introducing a word
> into the grammar that people already commonly know and use, and which is
> googlable if they don’t.
>
> I find b) to be quite convincing.
>
> Best,
>
> Josh
>
>
>
> Joshua Parmenter | Engineering Lead, Apple Technologies
>
> T 248 777 
> C 206 437 1551
> F 248 616 1980
> www.vectorform.com
>
> Vectorform
> 2107 Elliott Ave Suite 303
> Seattle, WA  98121 USA
>
> Think Tank. Lab. Studio.
> We invent digital products and experiences.
>
> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Joshua Alvarado
alvaradojosh...@gmail.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] guard let x = x

[Josh Parmenter via swift-evolution]

On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution 
> wrote:

To me, this is the most promising direction, but I’d suggest the use of 
“unwrap" as the keyword.  If you compare these two:

a) guard let foobar = foobar else { … }
b) guard unwrap foobar else { … }

I think that b) wins by virtue of eliminating repetition ("foobar = foobar" 
fails DRY principles), but retains clarity by introducing a word into the 
grammar that people already commonly know and use, and which is googlable if 
they don’t.

I find b) to be quite convincing.

Best,

Josh



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

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

[Erica Sadun via swift-evolution]

You and I discussed this at length in iOS Folks, but I'll restate here. I'd be 
against this proposal. I think it adds unnecessary verbosity vs a simple and 
elegant representation. As an inherently functional alternative to 
if-then-else, Swift's ternary form is clear and parsimonious, perfect for 
simple expressions. Converting to a more laborious syntax takes away these 
advantages, and I'd be tempted to write my own operators to mimic their 
functionality rather than use your syntax.

I'm glad you brought the proposal here and thank you for your effort in writing 
it up.

-- E


> On Oct 25, 2016, at 10:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> Preamble: I've read over the threads that already exist about the ternary 
> operator and to be honest they're a complete mess without a single fully 
> formed proposal.
> 
> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
> curve for newcomers when it comes to dealing with the ternary function. The 
> best way to do that, in my opinion, is to remove it entirely and add a new 
> function with better semantics that takes care of ternary operations entirely 
> within the Swift language.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
> 
> 
> Replace the `?:` operator with an in-language function

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

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

[Mark Sands via swift-evolution]

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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[William Sumner via swift-evolution]

> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution 
>  wrote:
> 
> Strong +1 from me.
> 
> This simply feels like the right approach for Swift, as we see the language 
> head in a direction that has abandoned traditional C-style idioms. As swift 
> has already dropped support for the ++/-- operators and C-style for loops it 
> makes logical sense that dropping the ternary operator (or replacing with a 
> more Swift-like idiom) should follow.
> 
> As a side note, after upgrading my swift code to Swift 3, I feel as though 
> I've become un-phased at future source breaking changes until full stability 
> is met and set in stone. If they're worth it, bring them on, I say.


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___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[Chris Lattner via swift-evolution]

On Oct 26, 2016, at 1:11 AM, alessandro aresta  wrote:
> Ensure is more comprehensible, guard is for sure "always" been there in older 
> languages... could it be kind of aliased somehow? I tend to confuse guard 
> sometimes, despite many few decades of using it.

No, we don’t introduce needless aliases for keywords like this.

I haven’t seen it mentioned on this thread yet, but we did consider “ensure” 
back when the guard statement was being designed for Swift 2.  We specifically 
avoided it because “ensure” is very much in the lexicon of pre and post 
conditions, and we want to reserve its use if/when we ever get there.

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

Re: [swift-evolution] guard let x = x

[Chris Lattner via swift-evolution]

> On Oct 26, 2016, at 8:58 AM, Erica Sadun via swift-evolution 
>  wrote:
>> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution 
>> > wrote:
>> 
>> Hey all,
>> 
>> As usual, apologies if this horse was beaten ages ago before I joined the 
>> mailing list, but thought I would bring this up.

Yes, this has thoroughly been beaten to death.  It is also outside the scope of 
Swift 4 stage 1.  That said, it is such a glaring problem that we’ll have to 
deal with it at some point.

>> I was typing the above (for the hundredth time) the other day and I was 
>> wondering whether it might be worth considering offering a shorter syntax:
>> 
>> guard let x, y, z else {…}

This specific syntax is commonly requested.  The problem with this is that it 
provides no useful information about what is actually going on: it sacrifices 
clarity to get terseness, a specific non-goal of Swift.


Erica says:
> Your initial suggestion doesn't work as overloading "let" confuses rather 
> than clarifies this process. In February, I brought up `bind x` to mean 
> "conditionally bind x to x, and produce a conditional fail if that's not 
> possible", with the hope that "bind self" could be used in closures. Under 
> that scheme your example would read:
> 
> guard bind x, bind y, bind z else { … }

To me, this is the most promising direction, but I’d suggest the use of 
“unwrap" as the keyword.  If you compare these two:

a) guard let foobar = foobar else { … }
b) guard unwrap foobar else { … }

I think that b) wins by virtue of eliminating repetition ("foobar = foobar" 
fails DRY principles), but retains clarity by introducing a word into the 
grammar that people already commonly know and use, and which is googlable if 
they don’t.

This also gives us the conceptual hook to make the “unwrapping an optional” 
behavior (which occurs with if let, optional chaining, etc) be something that 
could be extended to other similar user defined types, such as a Result type.

-Chris

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

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

[Erica Sadun via swift-evolution]

> On Oct 26, 2016, at 2:32 AM, Adrian Kashivskyy via swift-evolution 
>  wrote:
> 
> I’m -1 as it’s currently written, for the following reasons:
> 
> 1. Differences are introduced to pattern matching in different parts of the 
> language (`switch` vs `if`/`guard` vs `for`).

Pattern matching in Swift includes:

`switch case` and `for case`: The argument is pulled in indirectly:
`switch valuecase pattern:` and `for case pattern in sequence of values`

`guard case` and `if case`: The argument is expressed with an equal sign:
   `guard case pattern = value` and `if case pattern = value`

Operator use, excluding conditional binding: `pattern ~= value`.

I argue that the second group is closer to the third than the first because the 
value must be provided to the statement for `guard case`, `if case`, and the ~= 
operator.


> 2. Exclusion of `for` in the proposal is either deliberate (which relates to 
> point 1.) or done as a result of a rush, which is not good either. This 
> proposal should include a resolution for `for case let where` clauses.

Both `if case` and `guard case` don't use implied arguments, making them 
fundamentally a different type of check. If you insist that the keyword "case" 
be used for pattern matching, then under your argument it should appear in 
other parts of the language where pattern matching occurs. 

Since it doesn't, and you can check membership in a range with "range ~= 
value", why shouldn't the grammar for these two items be moved from the 
"passive implied arguments" group to the "explicit arguments" group, given that 
they use explicit arguments?

> 3. Syntatic sugar of optional matching `let x? ~= maybeX` feels completely 
> out of place and looks nothing like standard optional bindings. I will remain 
> strongly against this change.

I'd suggest that's a subjective issue with the sugar, not with the use of ~=. 

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

Re: [swift-evolution] guard let x = x

[Erica Sadun via swift-evolution]

> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution 
>  wrote:
> 
> Hey all,
> 
> As usual, apologies if this horse was beaten ages ago before I joined the 
> mailing list, but thought I would bring this up.
> 
> I was typing the above (for the hundredth time) the other day and I was 
> wondering whether it might be worth considering offering a shorter syntax:
> 
> guard let x, y, z else {…}
> 
> I was never convinced why implicit nil checks (i.e. if x {…}) were such a bad 
> thing.  But now in Swift it seems that it would be much more convenient to be 
> able to simply skip the assignment part of the expression and define the 
> above as guaranteeing and unwrapping x, y and z in the appropriate scope.
> 
> I think with such powerful and already compact expressions now wanting to get 
> on the same line,adding this would make the language even more compact and 
> elegant.  It could be added as a non-source-breaking change, still allowing x 
> = x for those who prefer it, but could significantly tighten up such uses, 
> which I’m finding are ubiquitous in my code.
> 
> Any thoughts?
> 
> -d

There are safety arguments to be made for introducing a way to bind an optional 
to a shadowed variable that is guaranteed to be the same name ensuring the 
conditionally bound item does not accidentally shadow any other item. 

Your initial suggestion doesn't work as overloading "let" confuses rather than 
clarifies this process. In February, I brought up `bind x` to mean 
"conditionally bind x to x, and produce a conditional fail if that's not 
possible", with the hope that "bind self" could be used in closures. Under that 
scheme your example would read:

guard bind x, bind y, bind z else { ... }

"The bind thread" was discussed during the first week of February 2016. Joe 
Groff had said: "If you all are serious about this, I think you should start a 
new thread about it."  I thought it was worth a serious discussion just so it 
could be evaluated and either adopted or discarded and dropped forever. The 
arguments for:

* Simplifying an mildly complex and potentially misleading statement 
* Creating a deliberate and controlled rather than accidental shadowing style

The discussion petered out, with Kevin Ballard making the strongest case 
against: "If your goal here is to just avoid having to write the `= foo`, then 
I disagree with the whole motive. If your goal here is to just use a keyword 
`bind` instead of `let` (e.g. if you want to use `if bind foo = foo { ... }`), 
I still disagree, because this new keyword serves no purpose. `if let foo = bar 
{ ... }` is not "fundamentally different" than `let foo = bar`, it's still 
binding a new identifier to a value, the only difference is it binds it to an 
optional value. And it's really just a specialization of `if case let foo? = 
bar { ... }`. I've asked in the past about whether it's worth keeping the 
special case around now that we have `if case let` (or more specifically, if we 
should just turn `if let` into the generalized version, so you'd say `if let 
foo? = bar {... }`) and the answer from the core team was that they already 
tried it internally and found that the usage of optionals was so prevalent that 
the special-case optional-specific form of `if let` was worth keeping."

There was not sufficient support to push forward with this, and reasonable 
arguments against. I'd suggest the long since beaten horse has moved on to a 
better world.

-- E


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

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

[Joshua Alvarado via swift-evolution]

-1

I love the idea of challenging the syntax but without any real benefit I can 
see it harder for new devs and it will cause breaking changes that doesn't 
outweigh the cause. The syntax z ? x : y is  not hard to comprehend and 
expresses powerful statements in just a simple line. I do agree it is abused. 
It is used in places that a fuller if statement would help make sense of the 
code. It is on the developer to help make the operator easier to understand. 
The operator is the same across many languages which helps create a standard. 

Alvarado, Joshua

> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution 
>  wrote:
> 
> Strong +1 from me.
> 
> This simply feels like the right approach for Swift, as we see the language 
> head in a direction that has abandoned traditional C-style idioms. As swift 
> has already dropped support for the ++/-- operators and C-style for loops it 
> makes logical sense that dropping the ternary operator (or replacing with a 
> more Swift-like idiom) should follow.
> 
> As a side note, after upgrading my swift code to Swift 3, I feel as though 
> I've become un-phased at future source breaking changes until full stability 
> is met and set in stone. If they're worth it, bring them on, I say.
> 
> Mark
> 
>> On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution 
>>  wrote:
>> I like the idea in theory, but I also like the existing ternary operator. 
>> Could some of this be accomplished without drastic changes?
>> 
>> Some alternative ideas-
>> 
>> 1) Codify ternary operator declaration in the language, but make some 
>> common-sense restrictions to reduce expression parsing complexity (no line 
>> breaks, enforced parens, 'simple' arguments, stuff like that).  If there 
>> were an extension like you propose in addition, my preference would be a 
>> verb like "select".
>> 
>> 2) Make it a binary operator with autoclosure tuple on the RHS (is it 
>> possible to put autoclosure within a tuple?):
>> 
>> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure () -> 
>> T, _ f: @autoclosure () -> T)) -> T {
>> if value {
>> return branches.t()
>> } else {
>> return branches.f()
>> }
>> }
>> 
>> 
>> 
>>> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via 
>>> swift-evolution  wrote:
>>> Preamble: I've read over the threads that already exist about the ternary 
>>> operator and to be honest they're a complete mess without a single fully 
>>> formed proposal.
>>> 
>>> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
>>> curve for newcomers when it comes to dealing with the ternary function. The 
>>> best way to do that, in my opinion, is to remove it entirely and add a new 
>>> function with better semantics that takes care of ternary operations 
>>> entirely within the Swift language.
>>> 
>>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>>> 
>>> Replace the `?:` operator with an in-language function
>>> 
>>> Proposal: TBD
>>> Author: [Charlotte Tortorella](https://github.com/qata)
>>> Editor: [Soroush Khanlou](https://github.com/khanlou)
>>> Review Manager: TBD
>>> Status: TBD
>>> 
>>> Introduction
>>> 
>>> The ternary operator in Swift was added early in development, as a holdover
>>> from C.  This document is an attempt to provide a clear look at the ternary
>>> operator without the baggage of the languages that came before, and comes
>>> to the conclusion that we should deprecate and remove the ternary operator
>>> in favor of an extension to `Bool`.
>>> 
>>> As a quick refresher, here's what the ternary operator looks like:
>>> 
>>> let a = 10
>>> let b = 20
>>> // If a is less than b, sets e to "foo", else sets e to "bar"
>>> let e = a < b ? "foo" : "bar"
>>> 
>>> Advantages of The Ternary Operator
>>> 
>>> The primary advantage of this operator is its terseness and expressive
>>> capability. It's shorthand for (e.g.):
>>> 
>>> let a = 10
>>> let b = 20
>>> let e: String
>>> if a < b {
>>>   e = "foo"
>>> } else {
>>>   e = "bar"
>>> }
>>> 
>>> The second advantage of Swift supporting the ternary operator is continuity
>>> with C, and other common languages in the extended C family (C++, 
>>> Objective-C,
>>> Java, C#, Javascript, etc).  People coming to Swift from these other 
>>> languages
>>> may reasonably expect this operator to exist.  That said, there are also
>>> popular languages which have kept the majority of C operators but dropped 
>>> the
>>> ternary operator (e.g. 
>>> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form) and 
>>> [Rust](https://github.com/rust-lang/rfcs/issues/1362)).
>>> 
>>> 
>>> Disadvantages of The Ternary Operator
>>> 
>>> 1. The existence of the ternary operator as a holdover from C is to increase
>>> the familiarity of the Swift language for C family developers, at the 
>>> expense
>>> of newcomers.  

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

[Mark Sands via swift-evolution]

Strong *+1* from me.

This simply feels like the right approach for Swift, as we see the language
head in a direction that has abandoned traditional C-style idioms. As swift
has already dropped support for the ++/-- operators and C-style for loops
it makes logical sense that dropping the ternary operator (or replacing
with a more Swift-like idiom) should follow.

As a side note, after upgrading my swift code to Swift 3, I feel as though
I've become un-phased at future source breaking changes until full
stability is met and set in stone. If they're worth it, bring them on, I
say.

Mark

On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution <
swift-evolution@swift.org> wrote:

> I like the idea in theory, but I also like the existing ternary operator.
> Could some of this be accomplished without drastic changes?
>
> Some alternative ideas-
>
> 1) Codify ternary operator declaration in the language, but make some
> common-sense restrictions to reduce expression parsing complexity (no line
> breaks, enforced parens, 'simple' arguments, stuff like that).  If there
> were an extension like you propose in addition, my preference would be a
> verb like "select".
>
> 2) Make it a binary operator with autoclosure tuple on the RHS (is it
> possible to put autoclosure within a tuple?):
>
> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure ()
> -> T, _ f: @autoclosure () -> T)) -> T {
> if value {
> return branches.t()
> } else {
> return branches.f()
> }
> }
>
>
>
> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via
> swift-evolution  wrote:
>
>> Preamble: I've read over the threads that already exist about the ternary
>> operator and to be honest they're a complete mess without a single fully
>> formed proposal.
>>
>> Pitch: I'd like to simplify the syntax, compiler complexity and learning
>> curve for newcomers when it comes to dealing with the ternary function. The
>> best way to do that, in my opinion, is to remove it entirely and add a new
>> function with better semantics that takes care of ternary operations
>> entirely within the Swift language.
>>
>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>>
>> Replace the `?:` operator with an in-language function
>>
>> Proposal: TBD
>> Author: [Charlotte Tortorella](https://github.com/qata)
>> Editor: [Soroush Khanlou](https://github.com/khanlou)
>> Review Manager: TBD
>> Status: TBD
>>
>> Introduction
>> 
>>
>> The ternary operator in Swift was added early in development, as a
>> holdover
>> from C.  This document is an attempt to provide a clear look at the
>> ternary
>> operator without the baggage of the languages that came before, and comes
>> to the conclusion that we should deprecate and remove the ternary operator
>> in favor of an extension to `Bool`.
>>
>> As a quick refresher, here's what the ternary operator looks like:
>>
>> let a = 10
>> let b = 20
>> // If a is less than b, sets e to "foo", else sets e to "bar"
>> let e = a < b ? "foo" : "bar"
>>
>> Advantages of The Ternary Operator
>> 
>>
>> The primary advantage of this operator is its terseness and expressive
>> capability. It's shorthand for (e.g.):
>>
>> let a = 10
>> let b = 20
>> let e: String
>> if a < b {
>>   e = "foo"
>> } else {
>>   e = "bar"
>> }
>>
>> The second advantage of Swift supporting the ternary operator is
>> continuity
>> with C, and other common languages in the extended C family (C++,
>> Objective-C,
>> Java, C#, Javascript, etc).  People coming to Swift from these other
>> languages
>> may reasonably expect this operator to exist.  That said, there are also
>> popular languages which have kept the majority of C operators but dropped
>> the
>> ternary operator (e.g. [Go](https://golang.org/doc/fa
>> q#Does_Go_have_a_ternary_form) and [Rust](https://github.com/rust
>> -lang/rfcs/issues/1362)).
>>
>>
>> Disadvantages of The Ternary Operator
>> 
>>
>> 1. The existence of the ternary operator as a holdover from C is to
>> increase
>> the familiarity of the Swift language for C family developers, at the
>> expense
>> of newcomers.  Established developers do much better with learning
>> concepts
>> than newcomers to programming and probably don't need their hands held
>> with this carry over of an operator.
>>
>> 2. The ternary operator adds complexity to the compiler, because it
>> requires
>> special handling.  It is the only operator that requires two components to
>> work (both the `?` and the `:`), it uses a character that is excluded from
>> being used in other operators (`:`), and it isn't defined in the standard
>> library.
>>
>> 3. The ternary operator's 

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

[Mike Kasianowicz via swift-evolution]

I like the idea in theory, but I also like the existing ternary operator.
Could some of this be accomplished without drastic changes?

Some alternative ideas-

1) Codify ternary operator declaration in the language, but make some
common-sense restrictions to reduce expression parsing complexity (no line
breaks, enforced parens, 'simple' arguments, stuff like that).  If there
were an extension like you propose in addition, my preference would be a
verb like "select".

2) Make it a binary operator with autoclosure tuple on the RHS (is it
possible to put autoclosure within a tuple?):

public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure () ->
T, _ f: @autoclosure () -> T)) -> T {
if value {
return branches.t()
} else {
return branches.f()
}
}



On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via
swift-evolution  wrote:

> Preamble: I've read over the threads that already exist about the ternary
> operator and to be honest they're a complete mess without a single fully
> formed proposal.
>
> Pitch: I'd like to simplify the syntax, compiler complexity and learning
> curve for newcomers when it comes to dealing with the ternary function. The
> best way to do that, in my opinion, is to remove it entirely and add a new
> function with better semantics that takes care of ternary operations
> entirely within the Swift language.
>
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>
> Replace the `?:` operator with an in-language function
>
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata)
> Editor: [Soroush Khanlou](https://github.com/khanlou)
> Review Manager: TBD
> Status: TBD
>
> Introduction
> 
>
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
>
> As a quick refresher, here's what the ternary operator looks like:
>
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
>
> Advantages of The Ternary Operator
> 
>
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
>
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
>
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++,
> Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other
> languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped
> the
> ternary operator (e.g. [Go](https://golang.org/doc/
> faq#Does_Go_have_a_ternary_form) and [Rust](https://github.com/
> rust-lang/rfcs/issues/1362)).
>
>
> Disadvantages of The Ternary Operator
> 
>
> 1. The existence of the ternary operator as a holdover from C is to
> increase
> the familiarity of the Swift language for C family developers, at the
> expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
>
> 2. The ternary operator adds complexity to the compiler, because it
> requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
>
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
>
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for
> variables,
> class inheritance, and protocol conformance.
>
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator anti-pattern.  This is similar to the `++` and
> `--` operators, which were removed in Swift 3.  While they worked fine and
> were
> readable enough when used alone, using them multiple times in a single
> expression like `function(a++, ++a)` made them highly unreadable and
> confusing.
>
> 6. This operator is only applicable to a single type, `Bool`.
>
> 7. If the ternary operator weren't in common usage, it would not 

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Haravikk via swift-evolution]

I'm a +1 on the basis that I wasn't even aware of the first case, so have never 
used it! Although I've used clone methods and such in the past, I've always 
done so with the generics specified so never noticed that I could omit them, 
however I do frequently run into the unexpected case that this proposal seeks 
to solve.

> On 11 Oct 2016, at 21:58, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> I was reminded of this proposal which seems like an obvious win in clarity. 
> Still planning to submit it, Slava?
> 
> — Pyry
> 
>> On 28 Jun 2016, at 21:13, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Thu Jun 23 2016, Slava Pestov  wrote:
>> 
>>> Simpler interpretation of a reference to a generic type with no
>>> arguments
>>> 
>>> Proposal: SE-
>>> 
>>> Author: Slava Pestov 
>>> Status: Awaiting review
>>> Review manager: TBD
>>> Introduction
>>> 
>>> This proposal cleans up the semantics of a reference to a generic type
>>> when no generic arguments are applied.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal
>>> 
>>> Motivation
>>> 
>>> Right now, we allow a generic type to be referenced with no generic
>>> arguments applied in a handful of special cases. The two primary rules
>>> here are the following:
>>> 
>>> If the scope from which the reference is made is nested inside the
>>> definition of the type or an extension thereof, omitting generic
>>> arguments just means to implicitly apply the arguments from context.
>>> 
>>> For example,
>>> 
>>> struct GenericBox {
>>> let contents: Contents
>>> 
>>> // Equivalent to: func clone() -> GenericBox
>>> func clone() -> GenericBox {
>>>   return GenericBox(contents: contents)
>>> }
>>> }
>>> 
>>> extension GenericBox {
>>> func print() {
>>>   // Equivalent to: let cloned: GenericBox
>>>   let cloned: GenericBox = clone()
>>>   print(cloned.contents)
>>> }
>>> }
>>> If the type is referenced from an unrelated scope, we attempt to infer
>>> the generic parameters.
>>> 
>>> For example,
>>> 
>>> func makeABox() -> GenericBox {
>>> // Equivalent to: GenericBox(contents: 123)
>>> return GenericBox(contents: 123)
>>> }
>>> The problem appears when the user expects the second behavior, but
>>> instead encounters the first. For example, the following does not type
>>> check:
>>> 
>>> extension GenericBox {
>>> 
>>> func transform(f: Contents -> T) -> GenericBox {
>>>   // We resolve 'GenericBox' as 'GenericBox', rather than
>>>   // inferring the type parameter
>>>   return GenericBox(contents: f(contents))
>>> }
>>> }
>>> Proposed
>>> solution
>>> 
>>> The proposed solution is to remove the first rule altogether. If the
>>> generic parameters cannot be inferred from context, they must be
>>> specified explicitly with the usual Type syntax.
>> 
>> SGTM.  I've always found this shorthand to be somewhat surprising,
>> including in C++ where (IIUC) it originated.
>> 
>> 
>> -- 
>> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[David Goodine via swift-evolution]

-1 as well, particularly agreeing with Rimantas that removing something of use 
because it confuses new programmers is not a good motivation.  To paraphrase 
Einstein, “A programming language should be as simple as possible, but no 
simpler.”

-d

> On Oct 26, 2016, at 6:26 AM, Rimantas Liubertas via swift-evolution 
>  wrote:
> 
> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
> curve for newcomers when it comes to dealing with the ternary function. The 
> best way to do that, in my opinion, is to remove it entirely and add a new 
> function with better semantics that takes care of ternary operations entirely 
> within the Swift language.
> 
> -1
> 
> A lot of things can and will be confusing for newcomers, that's not the 
> reason to remove them. Being a newbie is a transitional state.
> OTOH, I've never got why ternary is considered especially confusing, for me 
> it never was a problem and I love the terseness of it.
> Only total novices in programming may be surprised by it, but they will be 
> suprised by a lot of things anyway, so ternary is the least of their 
> problems. Those with experiene in other languages will be most likely already 
> familiar with the
> operator.
> Also, many come to Swift from Objective C, which not only has ternary, but 
> also supports a variant where you can use it kind of like ?? in Swift: 
> NSString *other = someString ?: @"default string".
> 
> Removing ?: gains nothing and loses a lot, I'd say.
> 
> Best regards,
> Rimantas
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] guard let x = x

[David Goodine via swift-evolution]

Hey all,

As usual, apologies if this horse was beaten ages ago before I joined the 
mailing list, but thought I would bring this up.

I was typing the above (for the hundredth time) the other day and I was 
wondering whether it might be worth considering offering a shorter syntax:

guard let x, y, z else {…}

I was never convinced why implicit nil checks (i.e. if x {…}) were such a bad 
thing.  But now in Swift it seems that it would be much more convenient to be 
able to simply skip the assignment part of the expression and define the above 
as guaranteeing and unwrapping x, y and z in the appropriate scope.

I think with such powerful and already compact expressions now wanting to get 
on the same line,adding this would make the language even more compact and 
elegant.  It could be added as a non-source-breaking change, still allowing x = 
x for those who prefer it, but could significantly tighten up such uses, which 
I’m finding are ubiquitous in my code.

Any thoughts?

-d

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

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

[Rimantas Liubertas via swift-evolution]

>
> Pitch: I'd like to simplify the syntax, compiler complexity and learning
> curve for newcomers when it comes to dealing with the ternary function. The
> best way to do that, in my opinion, is to remove it entirely and add a new
> function with better semantics that takes care of ternary operations
> entirely within the Swift language.
>

-1

A lot of things can and will be confusing for newcomers, that's not the
reason to remove them. Being a newbie is a transitional state.
OTOH, I've never got why ternary is considered especially confusing, for me
it never was a problem and I love the terseness of it.
Only total novices in programming may be surprised by it, but they will be
suprised by a lot of things anyway, so ternary is the least of their
problems. Those with experiene in other languages will be most likely
already familiar with the
operator.
Also, many come to Swift from Objective C, which not only has ternary, but
also supports a variant where you can use it kind of like ?? in Swift:
NSString *other = someString ?: @"default string".

Removing ?: gains nothing and loses a lot, I'd say.

Best regards,
Rimantas
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

[Brent Royal-Gordon via swift-evolution]

> This proposal replaces the current syntax with a simpler grammar that 
> prioritizes pattern matching but mirrors basic conditional binding. The new 
> syntax drops the case keyword and replaces = with ~=. The results look like 
> this:
> 
> guard let .success(value) ~= result { ... }
> guard .success(let value) ~= result { ... }
> if let .success(value) ~= result { ... }
> if .success(let value) ~= result { ... }
> guard let x? ~= anOptional { ... }
> if let x? ~= anOptional { ... }

I don't mind this syntax, but I'm not convinced this is worth doing if it's 
merely a syntax change. (It goes without saying that this is not phase 1.) But 
if it were motivated by a broader change, I think I could get behind it.

Suppose we introduced this concept:

protocol Pattern {
associatedtype Target
associatedtype Bindings

static func ~= (pattern: Self, target: Target) -> Bindings?
}

// Sometimes you just want the pattern on the other side.
func =~ (target: PatternType.Target, pattern: 
PatternType) -> PatternType.Bindings? {
return pattern ~= target
}

And further suppose that conditionals were altered to support `~=` and `=~` 
instead of `case =`. That is, a conditional with a pattern match in it would 
take the "then" branch if the `~=` returned `.some`, and would bind the 
variables in the returned tuple. In essence, this:

if pattern ~= target { … }

Would be rewritten to:

if let ([variables from pattern]) = (pattern ~= target) { … }

(One way to do this would be to support *any* Optional as a conditional, not 
just the results of a pattern match; this would essentially make `nil` into a 
false-ish value. But we tried that in the Swift 1 betas and didn't seem too 
happy with it.)

Enum cases would then have a dual nature; they could construct values, but they 
could also construct `Case` instances:

let value = Foo?.some(Foo())
// value: Foo?

let pattern1 = Foo?.some(let value) as Case
// pattern1: Case

let pattern2 = Foo?.some(_) as Case
// pattern2: Case

let pattern3 = Foo?.some as Case
// pattern3: Case

let aFoo = Foo()
let pattern4 = Foo?.some(aFoo) as Case
// pattern4: Case

Note that all four patterns are some variant of `Case`; it's just 
a matter of re-labeling the second parameter. Hopefully you could do that with 
a cast:

if (pattern as Case) ~= optionalFoo {
// use `foo` here
}

// Or with more powerful existentials:
if (pattern as Pattern where Bindings == (foo: Foo)) ~= fooTarget {
// use `foo` here
}

// Perhaps some sugar:
if fooTarget =~ pattern as let value {
// use `foo` here
}

Elements with a label are bound to a variable by that name; elements with no 
label are not bound to any variable. 

`Case` would look something like this, with the actual implementation of `~=` 
being compiler magic:

class Case: Pattern {
typealias Target = Enum
typealias Bindings = Associated

static func ~= (pattern: Case, target: Target) -> Bindings? { … 
}
}

(I suppose it might instead be `Enum.Case`—just depends on whether 
we want it to be magic or standard library-ish.)

So, what other patterns could we implement? Well, most notably, regular 
expressions:

class Regex: Pattern {
typealias Target = String
typealias Bindings = #concatenateTuples(($0: String), Captures)

static func ~= (pattern: RegularExpression, target: String) -> 
Bindings? { … }
}

 You would use them like this:

if /ab(.(.)?)c/ ~= myString {
// That's a Regex<($1: String, $2: String?)>.
// A named capture syntax would allow you to rename $1 and up, 
or you could cast 
// a regex you had received.
// If string slicing is corrected so that substrings share 
indices with their parent string, 
// you would not need a separate "get range of match" feature.
}

But here's another neat use case:

let gregorian = Calendar(identifier: .gregorian)
if myDate =~ DateComponents(calendar: gregorian, month: 10, day: 31) {
print("⚰")
}

extension DateComponents {
typealias Target = Date
typealias Bindings = (DateComponents)   // Optionally bindable

static func ~= (pattern: DateComponents, target: Target) -> 
Bindings? {
let calendar = self.calendar ?? 

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

[Anton Zhilin via swift-evolution]

infix operator ♠️ : LogicalDisjunctionPrecedenceinfix operator ♥ :
LogicalDisjunctionPrecedence
func ♠️(lhs: Bool, rhs: @autoclosure () throws -> T) rethrows -> T? {
if lhs { return rhs() } else { return nil }
}func ♥(lhs: T?, rhs: @autoclosure () throws -> T) rethrows -> T {
return lhs ?? rhs
}
// Equivalent statements:
condition() ? first() : second()
condition() ♠️ first() ♥ second()

By removal of ?:, we could simplify our system of operators and prevent
some ternary-related bugs/unexpected stuff. We could modify reserved
operators to allow ? instead of ♠️ and : instead of ♥.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Adrian Kashivskyy via swift-evolution]

I vote to incorporate it somehow into the “Universal Self 
”
 proposal.

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

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

[Adrian Kashivskyy via swift-evolution]

I’m -1 as it’s currently written, for the following reasons:

1. Differences are introduced to pattern matching in different parts of the 
language (`switch` vs `if`/`guard` vs `for`).

2. Exclusion of `for` in the proposal is either deliberate (which relates to 
point 1.) or done as a result of a rush, which is not good either. This 
proposal should include a resolution for `for case let where` clauses.

3. Syntatic sugar of optional matching `let x? ~= maybeX` feels completely out 
of place and looks nothing like standard optional bindings. I will remain 
strongly against this change.

– Adrian

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

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

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> Preamble: I've read over the threads that already exist about the ternary 
> operator and to be honest they're a complete mess without a single fully 
> formed proposal.
> 

You state the issue beautifully. Previous attempts have been "Complete mess" I 
agree. This is a commonly proposed feature and your solution unfortunately is 
not new. :( 

Replace ?: ternary operator: Definitely magical, but it serves a very important 
use-case for terse selection of different values. Proposals for alternatives 
have been intensely discussed, but none have been "better enough" for it to 
make sense to diverge from the precedent established by the C family of 
languages.



> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
> curve for newcomers when it comes to dealing with the ternary function. The 
> best way to do that, in my opinion, is to remove it entirely and add a new 
> function with better semantics that takes care of ternary operations entirely 
> within the Swift language.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
> 
> Replace the `?:` operator with an in-language function
> 
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata)
> Editor: [Soroush Khanlou](https://github.com/khanlou)
> Review Manager: TBD
> Status: TBD
> 
> Introduction
> 
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
> 
> As a quick refresher, here's what the ternary operator looks like:
> 
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
> 
> Advantages of The Ternary Operator
> 
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
> 
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
> 
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++, Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped the
> ternary operator (e.g. 
> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form) and 
> [Rust](https://github.com/rust-lang/rfcs/issues/1362)).
> 
> 
> Disadvantages of The Ternary Operator
> 
> 1. The existence of the ternary operator as a holdover from C is to increase
> the familiarity of the Swift language for C family developers, at the expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
> 
> 2. The ternary operator adds complexity to the compiler, because it requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
> 
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
> 
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for variables,
> class inheritance, and protocol conformance.
> 
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator anti-pattern.  This is similar to the `++` and
> `--` operators, which were removed in Swift 3.  While they worked fine and 
> were
> readable enough when used alone, using them multiple times in a single
> expression like `function(a++, ++a)` made them highly unreadable and
> confusing.
> 
> 6. This operator is only applicable to a single type, `Bool`.
> 
> 7. If the ternary operator weren't in common usage, it would not be proposed
> for Swift.  Higher clarity can be achieved with common language features by
> creating an extension to `Bool`.
> 
> 8. The ternary operator was created for and is much more suited to a language
> like C, where there were no generics and as such no alternative to an
> unintuitive operator.
> 
> 9. Several other modern languages, like Rust and Go discussed earlier, have
> eschewed the usage of the ternary operator entirely.  Other languages that 
> have
> special constructs similar to `?:`, such as `if then else` in Haskell have
> [discussed removing 
> 

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[alessandro aresta via swift-evolution]

Ensure is more comprehensible, guard is for sure "always" been there in
older languages... could it be kind of aliased somehow? I tend to confuse
guard sometimes, despite many few decades of using it.

On Wed, Oct 26, 2016 at 2:52 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Oct 25, 2016, at 10:20 AM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > At this point in Swift's evolution, source-breaking changes to the
> language require strong motivation. We can't really entertain superficial
> keyword changes like this without overwhelming evidence that the existing
> syntax is problematic in practice. `guard` has precedent in functional
> languages, for instance in Haskell where the `guard` function is
> idiomatically used as part of monadic `do`-notation computations, and has
> the same positive condition semantics in those languages.
>
> Right.  Jay, I’m sorry if you or others find the name “guard” to be
> confusing, but there are many Swift developers that like it.  I is almost
> inconceivable that we would change it at this point.
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
*Alessandro Alexander Stone Aresta*

senior development & consulting

*email  : performerst...@gmail.com *
*skype : alexanderstone2007*


*This  is  a  confidential   communication   intended   only  for  the
named addressee. *
* If you received this **communication **in **error, please notify
us  and return and delete it without  reading it. *

*This e-mail may not be *
*disclosed,  copied or distributed*
* in  **any form without the obtained permission in writing of  Alessandro
Aresta. *

*In  any case it  may not be altered or otherwise *

*changed.  *
* Whilst  Alessandro Aresta believes  that  the   information  is  correct
at  the date  of   the  e-mail,  no  warranty and *

*representation  is given to this effect and no responsibility can be
accepted by Alessandro Aresta.*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 26 Oct 2016, at 06:56, Charlotte Tortorella via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> I see, well with that in mind the proposal does set out how ?: is harmful to 
> comprehension of code for new programmers and I hope the pros and cons of 
> keeping it are thoroughly vetted. 
> 

They will be throughly vetted as any request is, but 1) I think the operator in 
question is easier to reason about that the alternative provided 2) this 
operator is not even in the league of the elements of the language which are 
important but may let you puzzled at first (good luck with explaining Swift 
unique take on protocol extension default methods to name one) and 3) I do not 
share a latent distaste for what C languages do and feel a need to distance 
ourselves from it (I would have kept the C style for loop, so I may not be the 
best one to ask about it ;)... or seen as things brewing when people argue 
about who is holier... I mean Swiftier and resulting Orthodoxy wars :P).

> Regards,
> Charlotte
> 
>> On 26 Oct. 2016, at 16:52, Chris Lattner  wrote:
>> 
>> 
 On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via 
 swift-evolution  wrote:
 
  Not a replacement for the Swift 4 source stability goal.
>>> 
>>> Swift 4 doesn't actually have a source stability goal. It has an ABI 
>>> stability goal. These are two very different things. ABI is the calling 
>>> conventions of the language.
>> 
>> Hi Charlotte,
>> 
>> Swift 4 has a strong source level compatibility goal.  This is explained in 
>> the main swift-evolution page and also in the proposal template:
>> https://github.com/apple/swift-evolution/blob/master/-template.md
>> 
>> "Relative to the Swift 3 evolution process, the source compatibility 
>> requirements for Swift 4 are much more stringent: we should only break 
>> source compatibility if the Swift 3 constructs were actively harmful in some 
>> way, the volume of affected Swift 3 code is relatively small, and we can 
>> provide source compatibility (in Swift 3 compatibility mode) and migration.”
>> 
>> I agree with you that a migrator could handle this change, but such a 
>> significant source breaking change still needs major justification for doing 
>> so.  Further in the Swift 3 timeframe, this very topic was hotly debated by 
>> the folks who wanted to turn the if statement into an expression 
>> (eliminating the need for the ?: operator).
>> 
>> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution