Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

2018-01-12 Thread Matthew Johnson via swift-evolution 

> On Jan 12, 2018, at 2:00 PM, John McCall via swift-evolution 
>  wrote:
> 
> 
>> On Jan 12, 2018, at 12:53 PM, BJ Homer via swift-evolution 
>> > wrote:
>> 
>> I agree that this behavior is annoying. However, wouldn’t it be 
>> source-breaking to change this now?
> 
> Source compatibility means that we can't change the behavior of Swift 3 / 
> Swift 4 source.  This would be a semantic change when building Swift 5 source 
> (or later).  There is no technical reason we couldn't make this change.  It 
> does need to meet a very high bar, because we are trying to avoid making 
> significant semantic breaks.  My personal sense is that it meets that bar 
> because double-optionals can be very confusing for novices and very annoying 
> for everyone else.
> 
> I think most use sites probably do want the optional-collapsing behavior.  
> 'try?' is already "sugar" syntax and should aim to be as convenient as 
> possible for the majority of use cases.  Much like the collapsing done by 
> optional chaining, I think you can come up with examples where somebody would 
> want the non-collapsing behavior, but it doesn't seem unreasonable to say 
> that they just shouldn't use the sugar.

I think I agree with this.  `try?` already has some implicit optional 
collapsing behavior when it is used in an expression where there is more than 
one call that can throw.  The most intuitive behavior is for this collapsing to 
compose with the collapsing of optional chaining.

> 
> John.
> 
>> 
>> -BJ
>> 
>>> On Jan 12, 2018, at 10:25 AM, Russ Bishop via swift-evolution 
>>> > wrote:
>>> 
>>> Greetings swift-evolution!
>>> 
>>> There is currently a disconnect between optional chaining and try? when it 
>>> comes to optional flattening:
>>> 
>>> 
>>> struct SomeType {
>>> func nonThrow() -> SomeType? { return self }
>>> func doThrow() throws -> SomeType? { return self }
>>> func nonOptional() throws -> SomeType { return self }
>>> }
>>> 
>>> let w = SomeType().nonThrow()?.nonThrow()?.nonThrow()?.nonThrow()
>>> // w has type SomeType?
>>> 
>>> let x = try? 
>>> SomeType().nonOptional().nonOptional().nonOptional().nonOptional()
>>> // x has type SomeType?
>>> 
>>> let y = try! SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
>>> // y has type SomeType?
>>> 
>>> let z = try? SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
>>> // z has type SomeType??
>>> 
>>> 
>>> We get a double-optional only when combining try? and optional-chaining. 
>>> That is inconvenient and it would be natural to have the compiler do the 
>>> flattening here.
>>> 
>>> 
>>> If anyone is interested in working on the proposal or implementation please 
>>> let me know. It would make a nice self-contained task if you're looking to 
>>> start contributing.
>>> 
>>> 
>>> Russ Bishop
>>>  Simulator
>>> 
>>> 
>>> ___
>>> 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 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] Make try? + optional chain flattening work together

2018-01-12 Thread John McCall via swift-evolution 

> On Jan 12, 2018, at 12:53 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> I agree that this behavior is annoying. However, wouldn’t it be 
> source-breaking to change this now?

Source compatibility means that we can't change the behavior of Swift 3 / Swift 
4 source.  This would be a semantic change when building Swift 5 source (or 
later).  There is no technical reason we couldn't make this change.  It does 
need to meet a very high bar, because we are trying to avoid making significant 
semantic breaks.  My personal sense is that it meets that bar because 
double-optionals can be very confusing for novices and very annoying for 
everyone else.

I think most use sites probably do want the optional-collapsing behavior.  
'try?' is already "sugar" syntax and should aim to be as convenient as possible 
for the majority of use cases.  Much like the collapsing done by optional 
chaining, I think you can come up with examples where somebody would want the 
non-collapsing behavior, but it doesn't seem unreasonable to say that they just 
shouldn't use the sugar.

John.

> 
> -BJ
> 
>> On Jan 12, 2018, at 10:25 AM, Russ Bishop via swift-evolution 
>> > wrote:
>> 
>> Greetings swift-evolution!
>> 
>> There is currently a disconnect between optional chaining and try? when it 
>> comes to optional flattening:
>> 
>> 
>> struct SomeType {
>> func nonThrow() -> SomeType? { return self }
>> func doThrow() throws -> SomeType? { return self }
>> func nonOptional() throws -> SomeType { return self }
>> }
>> 
>> let w = SomeType().nonThrow()?.nonThrow()?.nonThrow()?.nonThrow()
>> // w has type SomeType?
>> 
>> let x = try? 
>> SomeType().nonOptional().nonOptional().nonOptional().nonOptional()
>> // x has type SomeType?
>> 
>> let y = try! SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
>> // y has type SomeType?
>> 
>> let z = try? SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
>> // z has type SomeType??
>> 
>> 
>> We get a double-optional only when combining try? and optional-chaining. 
>> That is inconvenient and it would be natural to have the compiler do the 
>> flattening here.
>> 
>> 
>> If anyone is interested in working on the proposal or implementation please 
>> let me know. It would make a nice self-contained task if you're looking to 
>> start contributing.
>> 
>> 
>> Russ Bishop
>>  Simulator
>> 
>> 
>> ___
>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

2018-01-12 Thread Nevin Brackett-Rozinsky via swift-evolution 
This is not an optional-chaining issue *per se*. If you simply write,

let a = try? SomeType().doThrow()

// a has type SomeType??

you get a double-optional as well. Are you proposing to change that?

Nevin


On Fri, Jan 12, 2018 at 12:25 PM, Russ Bishop via swift-evolution <
swift-evolution@swift.org> wrote:

> Greetings swift-evolution!
>
> There is currently a disconnect between optional chaining and try? when it
> comes to optional flattening:
>
>
> struct SomeType {
> func nonThrow() -> SomeType? { return self }
> func doThrow() throws -> SomeType? { return self }
> func nonOptional() throws -> SomeType { return self }
> }
>
> let w = SomeType().nonThrow()?.nonThrow()?.nonThrow()?.nonThrow()
> // w has type SomeType?
>
> let x = try? SomeType().nonOptional().nonOptional().nonOptional().nonOpti
> onal()
> // x has type SomeType?
>
> let y = try! SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
> // y has type SomeType?
>
> let z = try? SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
> // z has type SomeType??
>
>
> We get a double-optional only when combining try? and optional-chaining.
> That is inconvenient and it would be natural to have the compiler do the
> flattening here.
>
>
> If anyone is interested in working on the proposal or implementation
> please let me know. It would make a nice self-contained task if you're
> looking to start contributing.
>
>
> Russ Bishop
>  Simulator
>
>
>
> ___
> 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] Make try? + optional chain flattening work together

2018-01-12 Thread BJ Homer via swift-evolution 
I agree that this behavior is annoying. However, wouldn’t it be source-breaking 
to change this now?

-BJ

> On Jan 12, 2018, at 10:25 AM, Russ Bishop via swift-evolution 
>  wrote:
> 
> Greetings swift-evolution!
> 
> There is currently a disconnect between optional chaining and try? when it 
> comes to optional flattening:
> 
> 
> struct SomeType {
> func nonThrow() -> SomeType? { return self }
> func doThrow() throws -> SomeType? { return self }
> func nonOptional() throws -> SomeType { return self }
> }
> 
> let w = SomeType().nonThrow()?.nonThrow()?.nonThrow()?.nonThrow()
> // w has type SomeType?
> 
> let x = try? 
> SomeType().nonOptional().nonOptional().nonOptional().nonOptional()
> // x has type SomeType?
> 
> let y = try! SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
> // y has type SomeType?
> 
> let z = try? SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
> // z has type SomeType??
> 
> 
> We get a double-optional only when combining try? and optional-chaining. That 
> is inconvenient and it would be natural to have the compiler do the 
> flattening here.
> 
> 
> If anyone is interested in working on the proposal or implementation please 
> let me know. It would make a nice self-contained task if you're looking to 
> start contributing.
> 
> 
> Russ Bishop
>  Simulator
> 
> 
> ___
> 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] Make try? + optional chain flattening work together

2018-01-12 Thread Russ Bishop via swift-evolution 
Greetings swift-evolution!

There is currently a disconnect between optional chaining and try? when it 
comes to optional flattening:


struct SomeType {
func nonThrow() -> SomeType? { return self }
func doThrow() throws -> SomeType? { return self }
func nonOptional() throws -> SomeType { return self }
}

let w = SomeType().nonThrow()?.nonThrow()?.nonThrow()?.nonThrow()
// w has type SomeType?

let x = try? SomeType().nonOptional().nonOptional().nonOptional().nonOptional()
// x has type SomeType?

let y = try! SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
// y has type SomeType?

let z = try? SomeType().doThrow()?.doThrow()?.doThrow()?.doThrow()
// z has type SomeType??


We get a double-optional only when combining try? and optional-chaining. That 
is inconvenient and it would be natural to have the compiler do the flattening 
here.


If anyone is interested in working on the proposal or implementation please let 
me know. It would make a nice self-contained task if you're looking to start 
contributing.


Russ Bishop
 Simulator


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