Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Georgios Moschovitis via swift-evolution]

> let last = array.last ?? fatalError(“array must not be empty”)

I prefer, the above, explicit version.

-g.

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jarod Long via swift-evolution]

Just wanted to throw in my preference for supporting both options. I'd also 
like to emphasize that !! isn't appealing just for the sake of terseness, but 
also because it completes the ?, ??, !, !! "family" of unwrapping operators in 
a way that reinforces their underlying concepts. In that sense, I think the 
addition of the operator actually makes the overall system more learnable 
through repeated application of a pattern.

Jarod

On Jun 30, 2017, 10:02 -0700, Dave DeLong via swift-evolution 
, wrote:
> These are good points, Brent.
>
>
> > On Jun 29, 2017, at 11:24 PM, Brent Royal-Gordon via swift-evolution 
> >  wrote:
> >
> > > On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
> > >  wrote:
> > >
> > > Using an operator to provide feedback on the context of a failed unwrap 
> > > has become a commonly implemented approach in the Swift developer 
> > > Community. What are your thoughts about adopting this widely-used 
> > > operator into the standard library?
> > >
> > > guard !lastItem.isEmpty else { return }
> > > let lastItem = array.last !! "Array must be non-empty"
> > >
> > > Details here:  
> > > https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
> > >
> > > Thank you for your thoughtful feedback, -- E
> >
> > Finally found a few minutes to read this thread.
> >
> > I'm a big fan of the `Never`-based approach. (I was before, but I am more 
> > so now.) Here are the points I can see in its favor:
> >
> > 1. It is extremely clear about what's happening—`!!` is another random 
> > operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> > fairly self-explanatory, and `??` is something you might already be using.
>
> !! is also clear about what’s happening, because it’s just like the existing 
> ! operator.
>
> > 2. It allows you to control the optimization behavior by using 
> > `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.
>
> Yep. That’s cool.
>
> > 3. If we later change `throw` from being a statement to being a 
> > `Never`-returning expression, you could use `throw` on the right-hand side 
> > of `??`.
>
> Neat idea. 👍
>
> > 4. It supports other `Never`-returning operations, like `abort()` or 
> > `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>
> Yep. That’s cool.
>
> > 5. It supports file-and-line error reporting without having to add any new 
> > features; `!!` could not do this because an operator can't have extra, 
> > defaulted parameters to carry the file and line.
>
> Erica’s proposal addresses this. Allowing operator functions to accept more 
> than 2 parameters that all have default arguments looks like it would be a 
> pretty straight-forward and non-controversial change. It would also allow the 
> FRP crowd to make their <~ and |> and ಠ_ಠ and (╯°□°)╯︵ ┻━┻ operators all 
> capture the #file and #line they’re used on, which would make debugging those 
> style of apps much easier.
>
> > 6. It harmonizes with the eventual idea of making `Never` a universal 
> > bottom type, but we don't actually have to implement that today, because we 
> > can just overload `??` for now.
>
> Yep. That’s cool.
>
> > Against these advantages, the only one I can see for `!!` is that it is 
> > terse. Terseness is good, especially for a feature which is competing with 
> > the single-character postfix `!` operator, but I can't help but be drawn to 
> > the flexibility and power of `??` with a `Never` expression on the 
> > right-hand side.
>
> I would argue that terseness is a goal of Swift. If it weren’t, we shouldn’t 
> have [Element] as sugar syntax for Array, or even a bunch of our 
> operators (postfix !, postfix ?, overflow checking operators, nil coalescing, 
> etc).
>
> IMO, having both !! that takes an error message and ?? that takes a () → 
> Never seem like worthwhile goals. The former allows me to be terse, yet still 
> expressive, and the latter allows me the customization to do what I want for 
> whatever is contextually appropriate in my situation.
>
> I don’t think anyone is arguing that ?? () → Never isn’t useful. The purpose 
> of this proposal is to put forward and defend the claim that “!! String” is 
> also useful and meets the barrier to entry in to the Standard Library.
>
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Robert Bennett via swift-evolution]

If/when Never is made a bottom time, I suppose this discussion will be moot 
because it will automatically work with ?? and the compiler would have to go 
out of its way to prevent that.

But until then, I much prefer guard-let-else to the proposed addition to ??. 
With a guard-let-else, the first word on the line tells you what’s going on, 
and when scanning through code you can quickly skim over that entire block as 
soon as you see “guard”. Guard-let-else makes it easy to understand the code at 
a glance. With the proposed addition to ??, you have to read all the way to the 
end of the line to understand that you’re exiting early with a fatal error. And 
in addition this lacks the flexibility of guard-let-else because you *must* 
fail; you cannot perform cleanup work and/or return gracefully.

While a convenient syntactic sugar, I foresee this addition making quickly 
understanding existing code much more difficult, and without much added 
convenience.

> On Jun 30, 2017, at 5:05 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Jun 30, 2017, at 5:38 AM, Matthew Johnson  wrote:
>>> 
>>> 3. If we later change `throw` from being a statement to being a 
>>> `Never`-returning expression, you could use `throw` on the right-hand side 
>>> of `??`.
>> 
>> What do you have in mind here?  I don't recall any discussion of `throw` 
>> return Never.  It seems like a novel use of a bottom type that might 
>> preclude the possibility of ever having a Result type that seamlessly 
>> bridges to Swift's error handling.  
> 
> 
> `throw` is currently a statement. Imagine, for sake of illustration, that it 
> was instead a function. This function would take an `Error` as a parameter 
> and throw it. It would never return normally—it would only return by 
> throwing—so its return type would be `Never`:
> 
>   @_implicitlyTry
>   func throw(_ error: Error) throws -> Never {
>   try Builtin.throw(error)
>   unreachable()
>   }
> 
> What I'm suggesting is that `throw` should remain a keyword, but should have 
> the semantics of this `throw(_:)` function. The parser should allow it in 
> expression context, the `try` checker should treat it as though it was 
> already marked `try`, and the type checker should treat it as an expression 
> that returns `Never` but can throw.
> 
> That would then allow you to say things like:
> 
>   let lastItem = array.last ?? throw MyError.arrayEmpty
> 
> It would not have any negative effect I can think of on `Result`. In fact, 
> trying to directly wrap a `throw SomeError.foo` statement in a `Result` would 
> produce a `Result`, correctly expressing the fact that the 
> result of that particular expression can never be successful.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Brent Royal-Gordon via swift-evolution]

> On Jun 30, 2017, at 5:38 AM, Matthew Johnson  wrote:
> 
>> 3. If we later change `throw` from being a statement to being a 
>> `Never`-returning expression, you could use `throw` on the right-hand side 
>> of `??`.
> 
> What do you have in mind here?  I don't recall any discussion of `throw` 
> return Never.  It seems like a novel use of a bottom type that might preclude 
> the possibility of ever having a Result type that seamlessly bridges to 
> Swift's error handling.  


`throw` is currently a statement. Imagine, for sake of illustration, that it 
was instead a function. This function would take an `Error` as a parameter and 
throw it. It would never return normally—it would only return by throwing—so 
its return type would be `Never`:

@_implicitlyTry
func throw(_ error: Error) throws -> Never {
try Builtin.throw(error)
unreachable()
}

What I'm suggesting is that `throw` should remain a keyword, but should have 
the semantics of this `throw(_:)` function. The parser should allow it in 
expression context, the `try` checker should treat it as though it was already 
marked `try`, and the type checker should treat it as an expression that 
returns `Never` but can throw.

That would then allow you to say things like:

let lastItem = array.last ?? throw MyError.arrayEmpty

It would not have any negative effect I can think of on `Result`. In fact, 
trying to directly wrap a `throw SomeError.foo` statement in a `Result` would 
produce a `Result`, correctly expressing the fact that the 
result of that particular expression can never be successful.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

These are good points, Brent.


> On Jun 29, 2017, at 11:24 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> Thank you for your thoughtful feedback, -- E
> 
> Finally found a few minutes to read this thread.
> 
> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
> now.) Here are the points I can see in its favor:
> 
> 1. It is extremely clear about what's happening—`!!` is another random 
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> fairly self-explanatory, and `??` is something you might already be using.

!! is also clear about what’s happening, because it’s just like the existing ! 
operator.

> 2. It allows you to control the optimization behavior by using `fatalError`, 
> `preconditionFailure`, or `assertionFailure` as desired.

Yep. That’s cool.

> 3. If we later change `throw` from being a statement to being a 
> `Never`-returning expression, you could use `throw` on the right-hand side of 
> `??`.

Neat idea. 👍 

> 4. It supports other `Never`-returning operations, like `abort()` or 
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.

Yep. That’s cool.

> 5. It supports file-and-line error reporting without having to add any new 
> features; `!!` could not do this because an operator can't have extra, 
> defaulted parameters to carry the file and line.

Erica’s proposal addresses this. Allowing operator functions to accept more 
than 2 parameters that all have default arguments looks like it would be a 
pretty straight-forward and non-controversial change. It would also allow the 
FRP crowd to make their <~ and |> and ಠ_ಠ and (╯°□°)╯︵ ┻━┻ operators all 
capture the #file and #line they’re used on, which would make debugging those 
style of apps much easier.

> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
> type, but we don't actually have to implement that today, because we can just 
> overload `??` for now.

Yep. That’s cool.

> Against these advantages, the only one I can see for `!!` is that it is 
> terse. Terseness is good, especially for a feature which is competing with 
> the single-character postfix `!` operator, but I can't help but be drawn to 
> the flexibility and power of `??` with a `Never` expression on the right-hand 
> side.

I would argue that terseness is a goal of Swift. If it weren’t, we shouldn’t 
have [Element] as sugar syntax for Array, or even a bunch of our 
operators (postfix !, postfix ?, overflow checking operators, nil coalescing, 
etc). 

IMO, having both !! that takes an error message and ?? that takes a () → Never 
seem like worthwhile goals. The former allows me to be terse, yet still 
expressive, and the latter allows me the customization to do what I want for 
whatever is contextually appropriate in my situation.

I don’t think anyone is arguing that ?? () → Never isn’t useful. The purpose of 
this proposal is to put forward and defend the claim that “!! String” is also 
useful and meets the barrier to entry in to the Standard Library.

Dave

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Elviro Rocca via swift-evolution]

Even if ?? is generally assumed as safe, fatalError would be there to clearly 
assert what's going on. This is true in general for fatalError, which presence 
in some code simply means that something could go wrong there, so the regular 
compilation-level safety cannot be a given. And as forced unwrapping, 
fatalError - and other failures caused by a precondition - is not something 
that should be used lightly.

I think that "?? fatalError()" clearly conveys the meaning, is future-proof and 
could be adopted as a best practice.


Elviro  

> Il giorno 30 giu 2017, alle ore 17:39, Jacob Williams via swift-evolution 
>  ha scritto:
> 
> I have been persuaded that extending the capabilities of the current ?? 
> operator has far more advantages than adding a new limited !! operator. While 
> I initially did not like the usage of the generally-assumed-safe ? for 
> throwing operations, the clarity provided by having to explicitly state your 
> ‘fatalError’ or ‘preconditionFailure’ etc, does make it obvious about what is 
> going on. 
> 
> Also, considering how this capability would eventually be possible with ?? 
> anyways once Never become a true bottom type, it does not make sense to add a 
> new operator that would essentially become deprecated in a short matter of 
> time anyways. As many people have stated, the bar for additions to the Swift 
> language should be, and is, exceptionally high. There just aren’t enough 
> pro’s for the !! operator to make it worthwhile.
> 
>> On Jun 30, 2017, at 9:31 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> These are all excellent points. I also feel they sidestep the motivation of 
>> the proposal. Even if there were a bottom `Never` and you could use `?? 
>> fatalError()`, I still think the language would benefit from `!!`.
>> 
>> As the language is right now, you can write your own "or die" function using 
>> a `guard` statement, overloading `??`, or implementing `!!`. Being able to 
>> duplicate an explanatory fail path isn't the point. Offering a 
>> best-practices alternative to `!!` that is easy to use, obvious to 
>> understand, and simple to adopt is.
>> 
>> As for the `#line` and `#file` issue, that is my biggest concern but I 
>> believe that can be surmounted.
>> 
>> -- E
>> 
>> 
>> 
>>> On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon >> > wrote:
>>> 
 On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Using an operator to provide feedback on the context of a failed unwrap 
 has become a commonly implemented approach in the Swift developer 
 Community. What are your thoughts about adopting this widely-used operator 
 into the standard library?
 
 guard !lastItem.isEmpty else { return }
 let lastItem = array.last !! "Array must be non-empty"
 
 Details here:  
 https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
 
 
 Thank you for your thoughtful feedback, -- E
>>> 
>>> Finally found a few minutes to read this thread.
>>> 
>>> I'm a big fan of the `Never`-based approach. (I was before, but I am more 
>>> so now.) Here are the points I can see in its favor:
>>> 
>>> 1. It is extremely clear about what's happening—`!!` is another random 
>>> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
>>> fairly self-explanatory, and `??` is something you might already be using.
>>> 
>>> 2. It allows you to control the optimization behavior by using 
>>> `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.
>>> 
>>> 3. If we later change `throw` from being a statement to being a 
>>> `Never`-returning expression, you could use `throw` on the right-hand side 
>>> of `??`.
>>> 
>>> 4. It supports other `Never`-returning operations, like `abort()` or 
>>> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>>> 
>>> 5. It supports file-and-line error reporting without having to add any new 
>>> features; `!!` could not do this because an operator can't have extra, 
>>> defaulted parameters to carry the file and line.
>>> 
>>> 6. It harmonizes with the eventual idea of making `Never` a universal 
>>> bottom type, but we don't actually have to implement that today, because we 
>>> can just overload `??` for now.
>>> 
>>> Against these advantages, the only one I can see for `!!` is that it is 
>>> terse. Terseness is good, especially for a feature which is competing with 
>>> the single-character postfix `!` operator, but I can't help but be drawn to 
>>> the flexibility and power of `??` with a `Never` expression on the 
>>> right-hand side.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> 

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

I have been persuaded that extending the capabilities of the current ?? 
operator has far more advantages than adding a new limited !! operator. While I 
initially did not like the usage of the generally-assumed-safe ? for throwing 
operations, the clarity provided by having to explicitly state your 
‘fatalError’ or ‘preconditionFailure’ etc, does make it obvious about what is 
going on. 

Also, considering how this capability would eventually be possible with ?? 
anyways once Never become a true bottom type, it does not make sense to add a 
new operator that would essentially become deprecated in a short matter of time 
anyways. As many people have stated, the bar for additions to the Swift 
language should be, and is, exceptionally high. There just aren’t enough pro’s 
for the !! operator to make it worthwhile.

> On Jun 30, 2017, at 9:31 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> These are all excellent points. I also feel they sidestep the motivation of 
> the proposal. Even if there were a bottom `Never` and you could use `?? 
> fatalError()`, I still think the language would benefit from `!!`.
> 
> As the language is right now, you can write your own "or die" function using 
> a `guard` statement, overloading `??`, or implementing `!!`. Being able to 
> duplicate an explanatory fail path isn't the point. Offering a best-practices 
> alternative to `!!` that is easy to use, obvious to understand, and simple to 
> adopt is.
> 
> As for the `#line` and `#file` issue, that is my biggest concern but I 
> believe that can be surmounted.
> 
> -- E
> 
> 
> 
>> On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Using an operator to provide feedback on the context of a failed unwrap has 
>>> become a commonly implemented approach in the Swift developer Community. 
>>> What are your thoughts about adopting this widely-used operator into the 
>>> standard library?
>>> 
>>> guard !lastItem.isEmpty else { return }
>>> let lastItem = array.last !! "Array must be non-empty"
>>> 
>>> Details here:  
>>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>>> 
>>> 
>>> Thank you for your thoughtful feedback, -- E
>> 
>> Finally found a few minutes to read this thread.
>> 
>> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
>> now.) Here are the points I can see in its favor:
>> 
>> 1. It is extremely clear about what's happening—`!!` is another random 
>> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
>> fairly self-explanatory, and `??` is something you might already be using.
>> 
>> 2. It allows you to control the optimization behavior by using `fatalError`, 
>> `preconditionFailure`, or `assertionFailure` as desired.
>> 
>> 3. If we later change `throw` from being a statement to being a 
>> `Never`-returning expression, you could use `throw` on the right-hand side 
>> of `??`.
>> 
>> 4. It supports other `Never`-returning operations, like `abort()` or 
>> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>> 
>> 5. It supports file-and-line error reporting without having to add any new 
>> features; `!!` could not do this because an operator can't have extra, 
>> defaulted parameters to carry the file and line.
>> 
>> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
>> type, but we don't actually have to implement that today, because we can 
>> just overload `??` for now.
>> 
>> Against these advantages, the only one I can see for `!!` is that it is 
>> terse. Terseness is good, especially for a feature which is competing with 
>> the single-character postfix `!` operator, but I can't help but be drawn to 
>> the flexibility and power of `??` with a `Never` expression on the 
>> right-hand side.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

These are all excellent points. I also feel they sidestep the motivation of the 
proposal. Even if there were a bottom `Never` and you could use `?? 
fatalError()`, I still think the language would benefit from `!!`.

As the language is right now, you can write your own "or die" function using a 
`guard` statement, overloading `??`, or implementing `!!`. Being able to 
duplicate an explanatory fail path isn't the point. Offering a best-practices 
alternative to `!!` that is easy to use, obvious to understand, and simple to 
adopt is.

As for the `#line` and `#file` issue, that is my biggest concern but I believe 
that can be surmounted.

-- E



> On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> Thank you for your thoughtful feedback, -- E
> 
> Finally found a few minutes to read this thread.
> 
> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
> now.) Here are the points I can see in its favor:
> 
> 1. It is extremely clear about what's happening—`!!` is another random 
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> fairly self-explanatory, and `??` is something you might already be using.
> 
> 2. It allows you to control the optimization behavior by using `fatalError`, 
> `preconditionFailure`, or `assertionFailure` as desired.
> 
> 3. If we later change `throw` from being a statement to being a 
> `Never`-returning expression, you could use `throw` on the right-hand side of 
> `??`.
> 
> 4. It supports other `Never`-returning operations, like `abort()` or 
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
> 
> 5. It supports file-and-line error reporting without having to add any new 
> features; `!!` could not do this because an operator can't have extra, 
> defaulted parameters to carry the file and line.
> 
> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
> type, but we don't actually have to implement that today, because we can just 
> overload `??` for now.
> 
> Against these advantages, the only one I can see for `!!` is that it is 
> terse. Terseness is good, especially for a feature which is competing with 
> the single-character postfix `!` operator, but I can't help but be drawn to 
> the flexibility and power of `??` with a `Never` expression on the right-hand 
> side.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Elviro Rocca via swift-evolution]

100% agree with everything. A custom operator is a good idea for operations 
that are actually frequent: once you learn what it means, it really helps 
reduce noise in code and improve readability. But forced unwrapping is 
something that's intended to be used sparsely.


Elviro


> Il giorno 30 giu 2017, alle ore 10:15, Víctor Pimentel Rodríguez via 
> swift-evolution  ha scritto:
> 
> On Fri, Jun 30, 2017 at 7:24 AM, Brent Royal-Gordon via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> Thank you for your thoughtful feedback, -- E
> 
> Finally found a few minutes to read this thread.
> 
> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
> now.) Here are the points I can see in its favor:
> 
> 1. It is extremely clear about what's happening—`!!` is another random 
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> fairly self-explanatory, and `??` is something you might already be using.
> 
> 2. It allows you to control the optimization behavior by using `fatalError`, 
> `preconditionFailure`, or `assertionFailure` as desired.
> 
> 3. If we later change `throw` from being a statement to being a 
> `Never`-returning expression, you could use `throw` on the right-hand side of 
> `??`.
> 
> 4. It supports other `Never`-returning operations, like `abort()` or 
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
> 
> 5. It supports file-and-line error reporting without having to add any new 
> features; `!!` could not do this because an operator can't have extra, 
> defaulted parameters to carry the file and line.
> 
> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
> type, but we don't actually have to implement that today, because we can just 
> overload `??` for now.
> 
> Against these advantages, the only one I can see for `!!` is that it is 
> terse. Terseness is good, especially for a feature which is competing with 
> the single-character postfix `!` operator, but I can't help but be drawn to 
> the flexibility and power of `??` with a `Never` expression on the right-hand 
> side.
> 
> +1 to everything.
> 
> If terseness is the only clear advantage of a new operator that is meant to 
> be used sparsely, it's clear to me that the ?? Never form is better for the 
> Swift community as a whole.
> 
> --
> Víctor Pimentel
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 30, 2017, at 12:24 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>> 
>> Thank you for your thoughtful feedback, -- E
> 
> Finally found a few minutes to read this thread.

Thanks for your thoughts Brent.  I generally agree.

> 
> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
> now.) Here are the points I can see in its favor:
> 
> 1. It is extremely clear about what's happening—`!!` is another random 
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> fairly self-explanatory, and `??` is something you might already be using.
> 
> 2. It allows you to control the optimization behavior by using `fatalError`, 
> `preconditionFailure`, or `assertionFailure` as desired.
> 
> 3. If we later change `throw` from being a statement to being a 
> `Never`-returning expression, you could use `throw` on the right-hand side of 
> `??`.

What do you have in mind here?  I don't recall any discussion of `throw` return 
Never.  It seems like a novel use of a bottom type that might preclude the 
possibility of ever having a Result type that seamlessly bridges to Swift's 
error handling.  

> 
> 4. It supports other `Never`-returning operations, like `abort()` or 
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
> 
> 5. It supports file-and-line error reporting without having to add any new 
> features; `!!` could not do this because an operator can't have extra, 
> defaulted parameters to carry the file and line.
> 
> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
> type, but we don't actually have to implement that today, because we can just 
> overload `??` for now.
> 
> Against these advantages, the only one I can see for `!!` is that it is 
> terse. Terseness is good, especially for a feature which is competing with 
> the single-character postfix `!` operator, but I can't help but be drawn to 
> the flexibility and power of `??` with a `Never` expression on the right-hand 
> side.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

+1 Well summarized.

The !! operator feels more like:

func !! (optional: T?, errorMessage: String) -> T {
   return optional ?? fatalError(errorMessage)
}
Which is totally unnecessary.



-- 
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2017 um 07:24:04, Brent Royal-Gordon via swift-evolution 
(swift-evolution@swift.org) schrieb:

On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
 wrote:

Using an operator to provide feedback on the context of a failed unwrap has 
become a commonly implemented approach in the Swift developer Community. What 
are your thoughts about adopting this widely-used operator into the standard 
library?

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b

Thank you for your thoughtful feedback, -- E

Finally found a few minutes to read this thread.

I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
now.) Here are the points I can see in its favor:

1. It is extremely clear about what's happening—`!!` is another random operator 
to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are fairly 
self-explanatory, and `??` is something you might already be using.

2. It allows you to control the optimization behavior by using `fatalError`, 
`preconditionFailure`, or `assertionFailure` as desired.

3. If we later change `throw` from being a statement to being a 
`Never`-returning expression, you could use `throw` on the right-hand side of 
`??`.

4. It supports other `Never`-returning operations, like `abort()` or `exit(_:)` 
or your custom `usage()` function, on the right side of `??`.

5. It supports file-and-line error reporting without having to add any new 
features; `!!` could not do this because an operator can't have extra, 
defaulted parameters to carry the file and line.

6. It harmonizes with the eventual idea of making `Never` a universal bottom 
type, but we don't actually have to implement that today, because we can just 
overload `??` for now.

Against these advantages, the only one I can see for `!!` is that it is terse. 
Terseness is good, especially for a feature which is competing with the 
single-character postfix `!` operator, but I can't help but be drawn to the 
flexibility and power of `??` with a `Never` expression on the right-hand side.

-- 
Brent Royal-Gordon
Architechies

___
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] Introducing the "Unwrap or Die" operator to the standard library

[Víctor Pimentel Rodríguez via swift-evolution]

On Fri, Jun 30, 2017 at 7:24 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Using an operator to provide feedback on the context of a failed unwrap
> has become a commonly implemented approach in the Swift developer
> Community. What are your thoughts about adopting this widely-used operator
> into the standard library?
>
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
>
> Details here:  https://gist.github.com/erica/
> 423e4b1c63b95c4c90338cdff4939a9b
>
> Thank you for your thoughtful feedback, -- E
>
>
> Finally found a few minutes to read this thread.
>
> I'm a big fan of the `Never`-based approach. (I was before, but I am more
> so now.) Here are the points I can see in its favor:
>
> 1. It is extremely clear about what's happening—`!!` is another random
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are
> fairly self-explanatory, and `??` is something you might already be using.
>
> 2. It allows you to control the optimization behavior by using
> `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.
>
> 3. If we later change `throw` from being a statement to being a
> `Never`-returning expression, you could use `throw` on the right-hand side
> of `??`.
>
> 4. It supports other `Never`-returning operations, like `abort()` or
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>
> 5. It supports file-and-line error reporting without having to add any new
> features; `!!` could not do this because an operator can't have extra,
> defaulted parameters to carry the file and line.
>
> 6. It harmonizes with the eventual idea of making `Never` a universal
> bottom type, but we don't actually have to implement that today, because we
> can just overload `??` for now.
>
> Against these advantages, the only one I can see for `!!` is that it is
> terse. Terseness is good, especially for a feature which is competing with
> the single-character postfix `!` operator, but I can't help but be drawn to
> the flexibility and power of `??` with a `Never` expression on the
> right-hand side.
>

+1 to everything.

If terseness is the only clear advantage of a new operator that is meant to
be used sparsely, it's clear to me that the ?? Never form is better for the
Swift community as a whole.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 30 Jun 2017, at 07:23, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>> 
>> Thank you for your thoughtful feedback, -- E
> 
> Finally found a few minutes to read this thread.
> 
> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
> now.) Here are the points I can see in its favor:
> 
> 1. It is extremely clear about what's happening—`!!` is another random 
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> fairly self-explanatory, and `??` is something you might already be using.
> 
> 2. It allows you to control the optimization behavior by using `fatalError`, 
> `preconditionFailure`, or `assertionFailure` as desired.
> 
> 3. If we later change `throw` from being a statement to being a 
> `Never`-returning expression, you could use `throw` on the right-hand side of 
> `??`.

Hadn't thought of that. That's really cool!

> 4. It supports other `Never`-returning operations, like `abort()` or 
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.

That's very important IMHO.

> 5. It supports file-and-line error reporting without having to add any new 
> features; `!!` could not do this because an operator can't have extra, 
> defaulted parameters to carry the file and line.
> 
> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
> type, but we don't actually have to implement that today, because we can just 
> overload `??` for now.
> 
> Against these advantages, the only one I can see for `!!` is that it is 
> terse. Terseness is good, especially for a feature which is competing with 
> the single-character postfix `!` operator, but I can't help but be drawn to 
> the flexibility and power of `??` with a `Never` expression on the right-hand 
> side.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Brent Royal-Gordon via swift-evolution]

> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Using an operator to provide feedback on the context of a failed unwrap has 
> become a commonly implemented approach in the Swift developer Community. What 
> are your thoughts about adopting this widely-used operator into the standard 
> library?
> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> 
> 
> Thank you for your thoughtful feedback, -- E

Finally found a few minutes to read this thread.

I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
now.) Here are the points I can see in its favor:

1. It is extremely clear about what's happening—`!!` is another random operator 
to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are fairly 
self-explanatory, and `??` is something you might already be using.

2. It allows you to control the optimization behavior by using `fatalError`, 
`preconditionFailure`, or `assertionFailure` as desired.

3. If we later change `throw` from being a statement to being a 
`Never`-returning expression, you could use `throw` on the right-hand side of 
`??`.

4. It supports other `Never`-returning operations, like `abort()` or `exit(_:)` 
or your custom `usage()` function, on the right side of `??`.

5. It supports file-and-line error reporting without having to add any new 
features; `!!` could not do this because an operator can't have extra, 
defaulted parameters to carry the file and line.

6. It harmonizes with the eventual idea of making `Never` a universal bottom 
type, but we don't actually have to implement that today, because we can just 
overload `??` for now.

Against these advantages, the only one I can see for `!!` is that it is terse. 
Terseness is good, especially for a feature which is competing with the 
single-character postfix `!` operator, but I can't help but be drawn to the 
flexibility and power of `??` with a `Never` expression on the right-hand side.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jaden Geller via swift-evolution]

> On Jun 29, 2017, at 7:35 PM, Yuta Koshizawa  wrote:
> 
> "In -Ounchecked builds, the optimizer may assume that this function is never 
> called. Failure to satisfy that assumption is a serious programming error.”
> 
> Yes, and so the following `!!` can perform identically to `!` in -Ounchecked 
> builds when it is inlined.

Yes, I guess I wasn’t clear. I mean that there’s no problem.

> public static func !!(optional: Optional, errorMessage:
> @autoclosure () -> String) -> Wrapped {
> precondition(optional != nil, errorMessage())
> return optional!
> }
> 
> --
> Yuta
> 
> 
> 2017-06-29 6:42 GMT+09:00 Jaden Geller  >:
> 
> > On Jun 28, 2017, at 7:47 AM, Erica Sadun via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> >
> >> On Jun 28, 2017, at 3:52 AM, Yuta Koshizawa via swift-evolution 
> >> mailto:swift-evolution@swift.org>> wrote:
> >>
> >> Hi, I think it is an orthogonal issue if we need a new operator. It is
> >> also possible to introduce an infix `!` for it.
> >>
> >> I am sure that we do not need to avoid `precondition` as long as we
> >> use it appropriately. It is useful to realize consistent behavior with
> >> `Array`'s `subscript`, forced unwrapping `!`, `&+` and so on. In this
> >> context, `precondition` does not mean a general word "precondition"
> >> but the `precondition` function in the Swift standard library, which
> >> is removed when -Ounchecked.
> >
> >
> > How would the line run then? Would it simply act as a forced unwrapped 
> > under -Ounchecked?
> 
> From the docs:
> 
> "In -Ounchecked builds, the optimizer may assume that this function is never 
> called. Failure to satisfy that assumption is a serious programming error.”
> 
> Aka, v. bad things happen if the precondition does not hold.
> 
> >
> > -- E
> >
> > ___
> > 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] Introducing the "Unwrap or Die" operator to the standard library

[Yuta Koshizawa via swift-evolution]

"In -Ounchecked builds, the optimizer may assume that this function is
never called. Failure to satisfy that assumption is a serious programming
error.”


Yes, and so the following `!!` can perform identically to `!` in
-Ounchecked builds when it is inlined.

public static func !!(optional: Optional, errorMessage: @autoclosure () ->
String) -> Wrapped { precondition(optional != nil, errorMessage()) return
optional! }

--
Yuta


2017-06-29 6:42 GMT+09:00 Jaden Geller :

>
> > On Jun 28, 2017, at 7:47 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On Jun 28, 2017, at 3:52 AM, Yuta Koshizawa via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Hi, I think it is an orthogonal issue if we need a new operator. It is
> >> also possible to introduce an infix `!` for it.
> >>
> >> I am sure that we do not need to avoid `precondition` as long as we
> >> use it appropriately. It is useful to realize consistent behavior with
> >> `Array`'s `subscript`, forced unwrapping `!`, `&+` and so on. In this
> >> context, `precondition` does not mean a general word "precondition"
> >> but the `precondition` function in the Swift standard library, which
> >> is removed when -Ounchecked.
> >
> >
> > How would the line run then? Would it simply act as a forced unwrapped
> under -Ounchecked?
>
> From the docs:
>
> "In -Ounchecked builds, the optimizer may assume that this function is
> never called. Failure to satisfy that assumption is a serious programming
> error.”
>
> Aka, v. bad things happen if the precondition does not hold.
>
> >
> > -- E
> >
> > ___
> > 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] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

Fixed. Finger slipped during spell correct and I thought I had backed up 
through enough items -- apparently I didn't. :(

-- E


> On Jun 29, 2017, at 2:29 PM, Rod Brown  wrote:
> 
> Thanks Erica. That looks great.
> 
> As a side-note, one of the sentences in “The Black Swan Deployment” 
> references a “Mackintosh” - I believe this was supposed to be “Hackintosh”.
> 
> 
>> On 30 Jun 2017, at 3:20 am, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jun 29, 2017, at 9:13 AM, Dave DeLong >> > wrote:
>>> 
>>> My usage of “!!” generally falls in to two big buckets:
>>> 
>> 
>> I've incorporated all the feedback to date and updated the gist:
>> 
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> -- E
>> 
>> 
>> ___
>> 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] Introducing the "Unwrap or Die" operator to the standard library

[Rod Brown via swift-evolution]

Thanks Erica. That looks great.

As a side-note, one of the sentences in “The Black Swan Deployment” references 
a “Mackintosh” - I believe this was supposed to be “Hackintosh”.


> On 30 Jun 2017, at 3:20 am, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 29, 2017, at 9:13 AM, Dave DeLong > > wrote:
>> 
>> My usage of “!!” generally falls in to two big buckets:
>> 
> 
> I've incorporated all the feedback to date and updated the gist:
> 
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> 
> 
> -- E
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

> On Jun 29, 2017, at 12:23 PM, Djura Retired Hunter via swift-evolution 
>  wrote:
> 
> 
>> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> ha scritto:
>> 
>> 
>>> On Jun 29, 2017, at 9:13 AM, Dave DeLong >> > wrote:
>>> 
>>> My usage of “!!” generally falls in to two big buckets:
>>> 
>> 
>> I've incorporated all the feedback to date and updated the gist:
>> 
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> -- E
> 
> In my opinion the phrase "An often-touted misconception ... a serious 
> failure." taken from Ben Cohen's comment should not be included in the 
> proposal because, other than being a personal opinion, it's a extremely 
> generic statement that doesn't suggest at all "when" force unwrap is good and 
> it's not useful as a guideline for people that read this things to learn 
> something. Saying things like "this is kind of ok but too much of it is 
> wrong" is not useful.
> 
>> // in a custom view controller subclass that only accepts children of a 
>> certain kind:
>> let existing = childViewControllers as? Array !! 
>> "TableViewController must only have TableRowViewControllers as children"
>> 
> 
> In my opinion this example shows very well how you can always switch the need 
> to force unwrap with a more specific contract for a class, or in other words, 
> with a more specific type. Instead of referring to childViewControllers, you 
> could simply have an array of objects of the specific type that mediates the 
> addition and reference to the underlying "childViewControllers" storage. It 
> uses the type system to enforce correctness.

This is getting off on a tangent, but the interface I wrote for my 
TableViewController does that.

However

Since it is a subclass of NS/UIViewController, the `childViewControllers` 
property is public and directly mutable by anyone. Thus, the assertion that the 
class is not being misused.

Dave

> 
> Now, I'm NOT saying that force unwrapping is always bad, but adding examples 
> like these to a official proposal could make people think that force 
> unwrapping is a perfectly fine thing to do for production code instead of 
> designing types for safety, and safety enforced with a strong type system IS 
> a cornerstone of Swift, like it or not, as reported on swift.org/about: 
>  "The most obvious way to write code should also 
> behave in a safe manner. Undefined behavior is the enemy of safety, and 
> developer mistakes should be caught before software is in production. Opting 
> for safety sometimes means Swift will feel strict, but we believe that 
> clarity saves time in the long run.".
> 
> 
> Elviro
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Rod Brown via swift-evolution]

> On 29 Jun 2017, at 11:18 am, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In the initial example, repeated here in largely identical form, the desired 
>> comment is "array must be non-empty." In what way does that provide more 
>> information than a bare `!`?
>> 
> 
> By the same token, why does precondition have an optional string? Why would 
> you ever want to write more than:
> 
> precondition(!array.isEmpty)
> 
> It’s self evident – the array must not be empty! Why the second argument? 
> 
> Because you might want a meaningful string to be output when the app traps. 
> And it gives you somewhere to document why it mustn’t be empty – the 
> explanation for the precondition rather than the precondition itself. 
> Similarly, when your app traps because of an unwrapped nil, it’s desirable to 
> get some output in your debug console telling you why straight away, rather 
> than have to hunt down the code, read the line that failed, then read the 
> context around the line, to understand the reason. This is even more 
> important if you didn’t write this code yourself.
> 
> Finally, there’s a woolier justification: there’s an often-touted 
> misconception out there that force unwraps are bad, that they were only 
> created to accommodate legacy apps, and that force-unwrapping is always bad 
> and you should never do it. This isn’t true – there are many good reasons to 
> use force unwrap (though if you reaching for it constantly it’s a bad sign). 
> Force-unwrapping is often better than just whacking in a default value or 
> optional chaining when the presence of nil would indicate a serious failure. 
> Introduction of the `!!` operator could help endorse/encourage the use of 
> “thoughtful” force-unwrapping, which often comes with a comment of the 
> reasoning why it’s safe (of why the array can’t be empty at this point, not 
> just that it is empty). And if you’re going to write a comment, why not make 
> that comment useful for debugging at the same time.

I’m so glad the above has been stated outright here. It’s a bugbear of mine 
hearing people preach that the ! operator is always wrong.

> 
> In cases where it’s really not necessary, ! would remain just like, when 
> you’re not really too fussed, you can leave off the string from a 
> precondition.
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Rob Mayoff via swift-evolution]

On Wed, Jun 28, 2017 at 8:49 PM, Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

> As the screener of a non-zero number of radars resulting from unwrapped
> nils, I would certainly appreciate more use of guard let x = x else {
> fatalError(“explanation”) } and hope that !! would encourage it.
>

Sure, but... a lot of unwrap-failed explanations are never going to be
printed because a lot of unwraps will never fail. We're going to spend time
writing those explanations, and we're going to increase the size of our
binaries. Maybe making the bug-screeners do more work is still a net win
for humanity.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Zach Waldowski via swift-evolution]

As much as I favor Swift's preference for API contracts, "I would just
write the code differently," is missing the point of this suggestion.
You can design a single function to look beautiful without any unwraps,
but in a system or a codebase, you must check those preconditions at
some point. If you are dealing with other paradigms that you can't
control, like Cocoa two-stage loading, you must check those
preconditions at some point.
Zach Waldowski
z...@waldowski.me

On Thu, Jun 29, 2017, at 01:43 PM, ilya via swift-evolution wrote:
> I'm not sure those examples are what we should aim for. Generally I
> try to avoid force unwrapping, and specifically in these cases I
> belive a more reliable code would be produced without either ! or the
> !! operators:> 
> https://gist.github.com/ilyannn/4c5530c75293db0324a04f50ae691b2a
> 
> I understand coding styles may differ, but I do worry that we
> "promote" force unwrapping too much by inroducing another
> operator for it.> 
> Ilya.
> 
> 
> On Thu, Jun 29, 2017 at 6:55 PM Erica Sadun via swift-evolution  evolut...@swift.org> wrote:>> 
>>> On Jun 29, 2017, at 9:13 AM, Dave DeLong  wrote:
>>> 
>>> My usage of “!!” generally falls in to two big buckets:
>>> 
>> 
>> I've incorporated all the feedback to date and updated the gist:
>> 
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>> 
>> -- E
>> 
>> 
>> ___
>>  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] Introducing the "Unwrap or Die" operator to the standard library

[Djura Retired Hunter via swift-evolution]

> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution 
>  ha scritto:
> 
> 
>> On Jun 29, 2017, at 9:13 AM, Dave DeLong > > wrote:
>> 
>> My usage of “!!” generally falls in to two big buckets:
>> 
> 
> I've incorporated all the feedback to date and updated the gist:
> 
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> 
> 
> -- E

In my opinion the phrase "An often-touted misconception ... a serious failure." 
taken from Ben Cohen's comment should not be included in the proposal because, 
other than being a personal opinion, it's a extremely generic statement that 
doesn't suggest at all "when" force unwrap is good and it's not useful as a 
guideline for people that read this things to learn something. Saying things 
like "this is kind of ok but too much of it is wrong" is not useful.

> // in a custom view controller subclass that only accepts children of a 
> certain kind:
> let existing = childViewControllers as? Array !! 
> "TableViewController must only have TableRowViewControllers as children"
> 

In my opinion this example shows very well how you can always switch the need 
to force unwrap with a more specific contract for a class, or in other words, 
with a more specific type. Instead of referring to childViewControllers, you 
could simply have an array of objects of the specific type that mediates the 
addition and reference to the underlying "childViewControllers" storage. It 
uses the type system to enforce correctness.

Now, I'm NOT saying that force unwrapping is always bad, but adding examples 
like these to a official proposal could make people think that force unwrapping 
is a perfectly fine thing to do for production code instead of designing types 
for safety, and safety enforced with a strong type system IS a cornerstone of 
Swift, like it or not, as reported on swift.org/about: "The most obvious way to 
write code should also behave in a safe manner. Undefined behavior is the enemy 
of safety, and developer mistakes should be caught before software is in 
production. Opting for safety sometimes means Swift will feel strict, but we 
believe that clarity saves time in the long run.".


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[ilya via swift-evolution]

I'm not sure those examples are what we should aim for. Generally I try to
avoid force unwrapping, and specifically in these cases I belive a more
reliable code would be produced without either ! or the !! operators:

https://gist.github.com/ilyannn/4c5530c75293db0324a04f50ae691b2a

I understand coding styles may differ, but I do worry that we "promote"
force unwrapping too much by inroducing another operator for it.

Ilya.


On Thu, Jun 29, 2017 at 6:55 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 29, 2017, at 9:13 AM, Dave DeLong  wrote:
>
> My usage of “!!” generally falls in to two big buckets:
>
>
> I've incorporated all the feedback to date and updated the gist:
>
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>
> -- E
>
>
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

> On Jun 29, 2017, at 9:13 AM, Dave DeLong  wrote:
> 
> My usage of “!!” generally falls in to two big buckets:
> 

I've incorporated all the feedback to date and updated the gist:

https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 


-- E


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

> On Jun 29, 2017, at 1:05 AM, David Hart via swift-evolution 
>  wrote:
> 
> I’ve taken time to digest all the messages on this discussion and would like 
> to summarise my point of view concerning several topics:
> 
> Usefulness of messages
> 
> Xiaodi seems to question the usefulness of attaching more information to the 
> failure case of an optional's unwrapping. To his credit, the original example 
> ("Array guaranteed non-empty") don’t add much. Instead, I think we should see 
> those strings as a great opportunity to add application-specific business 
> logic context that help debugging when the unwrapping fails. For example, 
> let’s imagine that I am handling the log out operation for a user I know 
> exists, I could write this:
> 
> let user = database.users[userId] !! “User to logout does not exist”

To expand on the usefulness of these messages, here’re some scattered examples 
of how I’ve been using this operator in an app I work on, pulled from various 
parts of the code:

// in a right-click gesture recognizer action handler
let event = NSApp.currentEvent !! "Trying to get current event for right click, 
but there's no event”

// in a custom view controller subclass that only accepts children of a certain 
kind:
let existing = childViewControllers as? Array !! 
"TableViewController must only have TableRowViewControllers as children"

// providing a value based on an initializer that returns an optional:
lazy var emptyURL: URL = { return URL(string: “myapp://section/\(identifier)") 
!! "can't create basic empty url” }()

// retrieving an image from an embedded framework:
private static let addImage: NSImage = {
let bundle = Bundle(for: FlagViewController.self)
let image = bundle.image(forResource: "add") !! "Missing 'add' image"
image.isTemplate = true
return image
}()

// asserting consistency of an internal model
let flag = command.flag(with: flagID) !! "Unable to retrieve non-custom flag 
for id \(flagID.string)"

My usage of “!!” generally falls in to two big buckets:

1. Asserting system framework correctness

For example, the “NSApp.currentEvent” property returns an 
Optional, because there’s not always a current event going on. That’s 
fine. But when I’m in the action handler of a right-click gesture recognizer it 
is safe to assert that I do have an event. If this ever fails, I have an 
immediately clear description of where the system framework has not worked 
according to my expectations.

2. Asserting app logic correctness

For example, I use this to assert that my outlets are properly hooked 
up (and the message tells me explicitly which outlet I’ve forgotten), or that 
my internal data model is in a consistent state.

Both areas of usage have been extremely helpful in building my app. They help 
me identify when I forget to put resources in the right target, or when I make 
changes to the internal model but forget all the places I’m supposed to insert 
things. They help me catch when I fat-finger a URL.

Yes, I could absolutely have done all of this with just a bare unwrap operator, 
but by putting the diagnostic message in there, I get immediate feedback as to 
why my code is failing. I don’t have to go digging around in the code in order 
to re-teach myself of what invariants are supposed to be held, because the 
error message gives me the succinct and immediately-actionable thing to do.

> Never and new operator
> 
> If we introduce the new operator !! solely with the String override, I still 
> have some doubts about it pulling its own weight. Of course, we could add a 
> () -> Never override to increase its usefulness:
> 
> let user = database.users[userId] !! “User to logout does not exist”
> let user = database.users[userId] !! logFatalError(“User to logout does not 
> exist”)

As I demonstrate above even just the string version can be extremely helpful.

> But Jaden Geller makes a very good point: if and once Never becomes a true 
> bottom type, that syntax will be redundant because Never will be usable with 
> the ?? operator, creating a lot of confusion:
> 
> let user = database.users[userId] !! logFatalError(“User to logout does not 
> exist”)
> let user = database.users[userId] ?? logFatalError(“User to logout does not 
> exist”)

Maybe the answer then is to add !! for strings, and then use ?? If you have a 
custom Never function.

> Those two lines will have exactly the same effect.
> 
> Cognitive Dissonance of Never and ??
> 
> Ben Cohen originally mentioned that if we introduce a () -> Never overload of 
> the ?? operator, there will be cognitive dissonance because the question mark 
> operator is never used in Swift to signal a trap. But if we make Never a true 
> bottom type, which has a lot of advantages, this dissonance will be 
> unavoidable. Shouldn’t we embrace it then?
> 
> Potential for confusion with multiple per line
> 
> This might not be a real concern, but are we introducing a syntax that will 

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Elviro Rocca via swift-evolution]

> Well, a persisted inconsistency is worse than a crash :P

I still strongly disagree with this, I'm sorry. Inconsistent data is an 
orthogonal problem to fatal errors, and a crash is basically a middle finger to 
the user. 

> To me this !! operator does not add enough value to put it in the standard 
> library. The existing force unwrap operator already works fine, and if Never 
> is really going to be a bottom type, then I don't know in which cases the !! 
> operator would be better.
> 
> Actually, for me it would be worse, because you could only call it with a 
> String or a function that returned a String. What happens if I want to call a 
> method that does some housekeeping and then ends with a fatalError? I could 
> not use the !! operator unless that method returns a String.
> 
> And finally, I would not want to find such code in a project with multiple 
> people involved, as my personal experience is that a single ! leads to 
> crashes in production sooner or later, and if you track such crashes it would 
> not be obvious why they happen. If that code is written by one person and 
> will not be published anywhere, I suppose you can use it, but either in open 
> source projects or in teams, I would avoid that operator like hell.
> 
> Instead of writing this (the original example, which by the way has a typo 
> :P):
> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> I would just write this:
> 
> guard let lastItem = array.last else { return }
> 
> The first example seems reasonable enough: you know that the array is empty, 
> you just checked for it! But that array may possible be a property of a class 
> and it can be changed in another thread, so you can't be so sure. And because 
> software is usually never finished, some other team mate can add more code 
> between the first line and the second line, making it easier to inadvertently 
> change the array contents and thus not preserving the initial invariants. The 
> second example may need to be rewritten if the requirements change, but it 
> does not have the same drawbacks as the initial example and, well, it's 
> definitely less code and easier to read.
> 
> Anyway, can we provide a real world example? If some projects are already 
> defining this operator, working examples must exist and we can analyze how 
> this operator affects the code and which patterns are leveraged by it.
> 

I agree with most of this, but I think the contraposition here is with:

guard let lastItem = array.last else { fatalError() }

> I understand your wish to never crash in production. But I think it’s an 
> ideal that is quite far from the day to day development practices of many 
> developers. If the philosophy of the Standard Library was to avoid all 
> production crashes, we wouldn’t have the following:
> 
> Implicitly unwrapped optionals
> Optional explicit unwrapping
> fatalError
> precondition
> 
> The fact is that we have those tools and that they are useful and used. I 
> salute your wish to ban all of the above in an effort to avoid all crashes in 
> production, but IMHO, it’s a style that is best enforced using a linter.

Swift is a language that doesn't enforce a particular style over the other 
(thankfully) so the standard library includes many constructs that can end up 
being mostly ignored by some people in some projects.

Because of that, I don't think that we should add to the standard library a 
particular construct just because some people use it in third party libraries, 
if the same behavior can be already accomplished with very minimal code using 
what's already there.

Also, avoiding all crashes in production is to me a fundamental value of 
software development, and is not particularly related to Swift or iOS or 
whatever. In fact, as was already written some posts before, logic errors are 
either mistakes or are used to avoid additional checks in cases when the 
overhead introduced by those checks is not acceptable from a performance 
standpoint, which is a very unfrequent case.

Now, during development I can decide to make something crash for informative 
reasons, so in general I'm not opposed at all to those constructs, but that 
doesn't justify production code that crashes due to implicit unwrapping or 
out-of-bounds errors. That's my opinion, and it's also my opinion that trusting 
a linter is a much weaker solution than actually enforcing the type-system and 
the compiler, and I'd say that Swift is not Objective-C or PHP, but that's a 
completely different topic.

Elviro

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 29 Jun 2017, at 12:37, Elviro Rocca  wrote:
> 
> From the user's standpoint, a crash is the worst thing possible, and should 
> always be avoided. A failure doesn't need to be silent for user, the app can 
> still communicate that there was an error with some kind of human readable 
> message, and the developer can still be informed via any service that 
> provides logging of non-fatal errors (there are many, most of them free).
> 
> During development, a crash can be informative, and that's what "assert" and 
> things like that are for: even if I still prefer to not crash, and handle 
> invariants by using specifically crafted types, I can understand the need for 
> crashing in development, and from that standpoint I'd definitely support a 
> proposal which goal is to make crashes caused by forced unwrapping more 
> informative for the developer, or to force the developer to make them more 
> informative (by substituting "!" with "!!").
> 
> The reason why I'm not completely convinced is the fact that there's already 
> "fatalError", and its presence already clearly indicates in the code that 
> something could trap there, in a verbally-appropriate way. In this sense a 
> new operator could encourage practices that in my opinion should not be 
> encouraged.

I understand your wish to never crash in production. But I think it’s an ideal 
that is quite far from the day to day development practices of many developers. 
If the philosophy of the Standard Library was to avoid all production crashes, 
we wouldn’t have the following:

Implicitly unwrapped optionals
Optional explicit unwrapping
fatalError
precondition

The fact is that we have those tools and that they are useful and used. I 
salute your wish to ban all of the above in an effort to avoid all crashes in 
production, but IMHO, it’s a style that is best enforced using a linter.

> Elviro
> 
>> Il giorno 29 giu 2017, alle ore 12:12, David Hart > > ha scritto:
>> 
>> 
>> 
>> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution 
 mailto:swift-evolution@swift.org>> ha scritto:
 
 Finally, there’s a woolier justification: there’s an often-touted 
 misconception out there that force unwraps are bad, that they were only 
 created to accommodate legacy apps, and that force-unwrapping is always 
 bad and you should never do it. This isn’t true – there are many good 
 reasons to use force unwrap (though if you reaching for it constantly it’s 
 a bad sign). Force-unwrapping is often better than just whacking in a 
 default value or optional chaining when the presence of nil would indicate 
 a serious failure. Introduction of the `!!` operator could help 
 endorse/encourage the use of “thoughtful” force-unwrapping, which often 
 comes with a comment of the reasoning why it’s safe (of why the array 
 can’t be empty at this point, not just that it is empty). And if you’re 
 going to write a comment, why not make that comment useful for debugging 
 at the same time.
 
>>> 
>>> If one could still just "!" I'm not sure that the "!!" would really 
>>> encourage a more thoughtful force unwrapping. Almost every crash related to 
>>> a force unwrap that I see from Swift beginners is 100% due to the fact that 
>>> adding and exclamation point makes the code compile, so they add it.
>>> 
>>> Also, I strongly disagree with your statement that the idea that 
>>> force-unwraps are bad is a misconception: if something is Optional, there's 
>>> a reason why it is, otherwise it would not be Optional at all, and that's 
>>> the reason why Optional exists in Swift and represents a substantial 
>>> technological advancement over Objective-C. Using an Optional means that we 
>>> are actually adding a thoughtful information to an instance: it could be 
>>> there, or it could not, and that's perfectly fine. Crashing an app in 
>>> production for a force-unwrap results in the poorest user experience ever, 
>>> and it should never happen.
>> 
>> If forced unwraps are only used in instances where you specifically expect 
>> the optional to not be nil, it is essentially sugar for a guard with 
>> preconditionFailure: it is used to enforce invariants the app should never 
>> break. It is very similar to a trap when accessing an out of bounds index in 
>> an array. In those cases, I actually prefer it crashing than having the app 
>> silently fail for the user, and you never finding out.
>> 
>> I try to limit my use of optional unwrapping but there are sometimes quite 
>> useful. IMHO, they are not inherently bad, but can be badly used.
>> 
>>> I feel compelled to link another article, where Soroush Khanlou shows that 
>>> sometimes the bare semantics of an Optional (that is, something is there or 
>>> not) is not enough: http://khanlou.com/2017/03/that-one-option

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Víctor Pimentel Rodríguez via swift-evolution]

On Thu, Jun 29, 2017 at 12:45 PM, Elviro Rocca via swift-evolution <
swift-evolution@swift.org> wrote:

> From the user's standpoint, a crash is the worst thing possible, and
> should always be avoided. A failure doesn't need to be silent for user, the
> app can still communicate that there was an error with some kind of human
> readable message, and the developer can still be informed via any service
> that provides logging of non-fatal errors (there are many, most of them
> free).
>

Well, a persisted inconsistency is worse than a crash :P

During development, a crash can be informative, and that's what "assert"
> and things like that are for: even if I still prefer to not crash, and
> handle invariants by using specifically crafted types, I can understand the
> need for crashing in development, and from that standpoint I'd definitely
> support a proposal which goal is to make crashes caused by forced
> unwrapping more informative for the developer, or to force the developer to
> make them more informative (by substituting "!" with "!!").
>
> The reason why I'm not completely convinced is the fact that there's
> already "fatalError", and its presence already clearly indicates in the
> code that something could trap there, in a verbally-appropriate way. In
> this sense a new operator could encourage practices that in my opinion
> should not be encouraged.
>
>
> Elviro
>

To me this !! operator does not add enough value to put it in the standard
library. The existing force unwrap operator already works fine, and if
Never is really going to be a bottom type, then I don't know in which cases
the !! operator would be better.

Actually, for me it would be worse, because you could only call it with a
String or a function that returned a String. What happens if I want to call
a method that does some housekeeping and then ends with a fatalError? I
could not use the !! operator unless that method returns a String.

And finally, I would not want to find such code in a project with multiple
people involved, as my personal experience is that a single ! leads to
crashes in production sooner or later, and if you track such crashes it
would not be obvious why they happen. If that code is written by one person
and will not be published anywhere, I suppose you can use it, but either in
open source projects or in teams, I would avoid that operator like hell.

Instead of writing this (the original example, which by the way has a typo
:P):

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

I would just write this:

guard let lastItem = array.last else { return }

The first example seems reasonable enough: you know that the array is
empty, you just checked for it! But that array may possible be a property
of a class and it can be changed in another thread, so you can't be so
sure. And because software is usually never finished, some other team mate
can add more code between the first line and the second line, making it
easier to inadvertently change the array contents and thus not preserving
the initial invariants. The second example may need to be rewritten if the
requirements change, but it does not have the same drawbacks as the initial
example and, well, it's definitely less code and easier to read.

Anyway, can we provide a real world example? If some projects are already
defining this operator, working examples must exist and we can analyze how
this operator affects the code and which patterns are leveraged by it.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Elviro Rocca via swift-evolution]

>From the user's standpoint, a crash is the worst thing possible, and should 
>always be avoided. A failure doesn't need to be silent for user, the app can 
>still communicate that there was an error with some kind of human readable 
>message, and the developer can still be informed via any service that provides 
>logging of non-fatal errors (there are many, most of them free).

During development, a crash can be informative, and that's what "assert" and 
things like that are for: even if I still prefer to not crash, and handle 
invariants by using specifically crafted types, I can understand the need for 
crashing in development, and from that standpoint I'd definitely support a 
proposal which goal is to make crashes caused by forced unwrapping more 
informative for the developer, or to force the developer to make them more 
informative (by substituting "!" with "!!").

The reason why I'm not completely convinced is the fact that there's already 
"fatalError", and its presence already clearly indicates in the code that 
something could trap there, in a verbally-appropriate way. In this sense a new 
operator could encourage practices that in my opinion should not be encouraged.


Elviro

> Il giorno 29 giu 2017, alle ore 12:12, David Hart  ha 
> scritto:
> 
> 
> 
> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> ha scritto:
>>> 
>>> Finally, there’s a woolier justification: there’s an often-touted 
>>> misconception out there that force unwraps are bad, that they were only 
>>> created to accommodate legacy apps, and that force-unwrapping is always bad 
>>> and you should never do it. This isn’t true – there are many good reasons 
>>> to use force unwrap (though if you reaching for it constantly it’s a bad 
>>> sign). Force-unwrapping is often better than just whacking in a default 
>>> value or optional chaining when the presence of nil would indicate a 
>>> serious failure. Introduction of the `!!` operator could help 
>>> endorse/encourage the use of “thoughtful” force-unwrapping, which often 
>>> comes with a comment of the reasoning why it’s safe (of why the array can’t 
>>> be empty at this point, not just that it is empty). And if you’re going to 
>>> write a comment, why not make that comment useful for debugging at the same 
>>> time.
>>> 
>> 
>> If one could still just "!" I'm not sure that the "!!" would really 
>> encourage a more thoughtful force unwrapping. Almost every crash related to 
>> a force unwrap that I see from Swift beginners is 100% due to the fact that 
>> adding and exclamation point makes the code compile, so they add it.
>> 
>> Also, I strongly disagree with your statement that the idea that 
>> force-unwraps are bad is a misconception: if something is Optional, there's 
>> a reason why it is, otherwise it would not be Optional at all, and that's 
>> the reason why Optional exists in Swift and represents a substantial 
>> technological advancement over Objective-C. Using an Optional means that we 
>> are actually adding a thoughtful information to an instance: it could be 
>> there, or it could not, and that's perfectly fine. Crashing an app in 
>> production for a force-unwrap results in the poorest user experience ever, 
>> and it should never happen.
> 
> If forced unwraps are only used in instances where you specifically expect 
> the optional to not be nil, it is essentially sugar for a guard with 
> preconditionFailure: it is used to enforce invariants the app should never 
> break. It is very similar to a trap when accessing an out of bounds index in 
> an array. In those cases, I actually prefer it crashing than having the app 
> silently fail for the user, and you never finding out.
> 
> I try to limit my use of optional unwrapping but there are sometimes quite 
> useful. IMHO, they are not inherently bad, but can be badly used.
> 
>> I feel compelled to link another article, where Soroush Khanlou shows that 
>> sometimes the bare semantics of an Optional (that is, something is there or 
>> not) is not enough: http://khanlou.com/2017/03/that-one-optional-property/ 
>> 
>> 
>> I also disagree with the idea that the "?? fatalError()" alternative suffers 
>> from cognitive dissonance, for the following reasons:
>> 
>> - on the right of the "??" operator there could be both an Optional or a 
>> non-Optional, which would result in a different type for the resulting 
>> instance;
>> - fatalError() by itself is an operation that changes the meaning of a 
>> function, making it non-total, and its very name conveys a clear meaning to 
>> a person that reads the code, thus it really doesn't seem to me that "?? 
>> fatalError()" could be misinterpreted;
>> 
>> Anyway, it would be interesting to consider "!! message" as an alternative 
>> to "!", thus

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution 
>  wrote:
> 
> 
>> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution 
>>  ha scritto:
>> 
>> Finally, there’s a woolier justification: there’s an often-touted 
>> misconception out there that force unwraps are bad, that they were only 
>> created to accommodate legacy apps, and that force-unwrapping is always bad 
>> and you should never do it. This isn’t true – there are many good reasons to 
>> use force unwrap (though if you reaching for it constantly it’s a bad sign). 
>> Force-unwrapping is often better than just whacking in a default value or 
>> optional chaining when the presence of nil would indicate a serious failure. 
>> Introduction of the `!!` operator could help endorse/encourage the use of 
>> “thoughtful” force-unwrapping, which often comes with a comment of the 
>> reasoning why it’s safe (of why the array can’t be empty at this point, not 
>> just that it is empty). And if you’re going to write a comment, why not make 
>> that comment useful for debugging at the same time.
>> 
> 
> If one could still just "!" I'm not sure that the "!!" would really encourage 
> a more thoughtful force unwrapping. Almost every crash related to a force 
> unwrap that I see from Swift beginners is 100% due to the fact that adding 
> and exclamation point makes the code compile, so they add it.
> 
> Also, I strongly disagree with your statement that the idea that 
> force-unwraps are bad is a misconception: if something is Optional, there's a 
> reason why it is, otherwise it would not be Optional at all, and that's the 
> reason why Optional exists in Swift and represents a substantial 
> technological advancement over Objective-C. Using an Optional means that we 
> are actually adding a thoughtful information to an instance: it could be 
> there, or it could not, and that's perfectly fine. Crashing an app in 
> production for a force-unwrap results in the poorest user experience ever, 
> and it should never happen.

If forced unwraps are only used in instances where you specifically expect the 
optional to not be nil, it is essentially sugar for a guard with 
preconditionFailure: it is used to enforce invariants the app should never 
break. It is very similar to a trap when accessing an out of bounds index in an 
array. In those cases, I actually prefer it crashing than having the app 
silently fail for the user, and you never finding out.

I try to limit my use of optional unwrapping but there are sometimes quite 
useful. IMHO, they are not inherently bad, but can be badly used.

> I feel compelled to link another article, where Soroush Khanlou shows that 
> sometimes the bare semantics of an Optional (that is, something is there or 
> not) is not enough: http://khanlou.com/2017/03/that-one-optional-property/
> 
> I also disagree with the idea that the "?? fatalError()" alternative suffers 
> from cognitive dissonance, for the following reasons:
> 
> - on the right of the "??" operator there could be both an Optional or a 
> non-Optional, which would result in a different type for the resulting 
> instance;
> - fatalError() by itself is an operation that changes the meaning of a 
> function, making it non-total, and its very name conveys a clear meaning to a 
> person that reads the code, thus it really doesn't seem to me that "?? 
> fatalError()" could be misinterpreted;
> 
> Anyway, it would be interesting to consider "!! message" as an alternative to 
> "!", thus forcing the user to at least do extra effort: that could discourage 
> a light use of !.
> 
> 
> Elviro
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Elviro Rocca via swift-evolution]

> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution 
>  ha scritto:
> 
> Finally, there’s a woolier justification: there’s an often-touted 
> misconception out there that force unwraps are bad, that they were only 
> created to accommodate legacy apps, and that force-unwrapping is always bad 
> and you should never do it. This isn’t true – there are many good reasons to 
> use force unwrap (though if you reaching for it constantly it’s a bad sign). 
> Force-unwrapping is often better than just whacking in a default value or 
> optional chaining when the presence of nil would indicate a serious failure. 
> Introduction of the `!!` operator could help endorse/encourage the use of 
> “thoughtful” force-unwrapping, which often comes with a comment of the 
> reasoning why it’s safe (of why the array can’t be empty at this point, not 
> just that it is empty). And if you’re going to write a comment, why not make 
> that comment useful for debugging at the same time.
> 

If one could still just "!" I'm not sure that the "!!" would really encourage a 
more thoughtful force unwrapping. Almost every crash related to a force unwrap 
that I see from Swift beginners is 100% due to the fact that adding and 
exclamation point makes the code compile, so they add it.

Also, I strongly disagree with your statement that the idea that force-unwraps 
are bad is a misconception: if something is Optional, there's a reason why it 
is, otherwise it would not be Optional at all, and that's the reason why 
Optional exists in Swift and represents a substantial technological advancement 
over Objective-C. Using an Optional means that we are actually adding a 
thoughtful information to an instance: it could be there, or it could not, and 
that's perfectly fine. Crashing an app in production for a force-unwrap results 
in the poorest user experience ever, and it should never happen.

I feel compelled to link another article, where Soroush Khanlou shows that 
sometimes the bare semantics of an Optional (that is, something is there or 
not) is not enough: http://khanlou.com/2017/03/that-one-optional-property/ 


I also disagree with the idea that the "?? fatalError()" alternative suffers 
from cognitive dissonance, for the following reasons:

- on the right of the "??" operator there could be both an Optional or a 
non-Optional, which would result in a different type for the resulting instance;
- fatalError() by itself is an operation that changes the meaning of a 
function, making it non-total, and its very name conveys a clear meaning to a 
person that reads the code, thus it really doesn't seem to me that "?? 
fatalError()" could be misinterpreted;

Anyway, it would be interesting to consider "!! message" as an alternative to 
"!", thus forcing the user to at least do extra effort: that could discourage a 
light use of !.


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

I’ve taken time to digest all the messages on this discussion and would like to 
summarise my point of view concerning several topics:

Usefulness of messages

Xiaodi seems to question the usefulness of attaching more information to the 
failure case of an optional's unwrapping. To his credit, the original example 
("Array guaranteed non-empty") don’t add much. Instead, I think we should see 
those strings as a great opportunity to add application-specific business logic 
context that help debugging when the unwrapping fails. For example, let’s 
imagine that I am handling the log out operation for a user I know exists, I 
could write this:

let user = database.users[userId] !! “User to logout does not exist”

Never and new operator

If we introduce the new operator !! solely with the String override, I still 
have some doubts about it pulling its own weight. Of course, we could add a () 
-> Never override to increase its usefulness:

let user = database.users[userId] !! “User to logout does not exist”
let user = database.users[userId] !! logFatalError(“User to logout does not 
exist”)

But Jaden Geller makes a very good point: if and once Never becomes a true 
bottom type, that syntax will be redundant because Never will be usable with 
the ?? operator, creating a lot of confusion:

let user = database.users[userId] !! logFatalError(“User to logout does not 
exist”)
let user = database.users[userId] ?? logFatalError(“User to logout does not 
exist”)

Those two lines will have exactly the same effect.

Cognitive Dissonance of Never and ??

Ben Cohen originally mentioned that if we introduce a () -> Never overload of 
the ?? operator, there will be cognitive dissonance because the question mark 
operator is never used in Swift to signal a trap. But if we make Never a true 
bottom type, which has a lot of advantages, this dissonance will be 
unavoidable. Shouldn’t we embrace it then?

Potential for confusion with multiple per line

This might not be a real concern, but are we introducing a syntax that will 
make it possible/encourage people to write less than readable code?

let user = (database !! “Database is not operational”).users[userId !! “User 
was not set in time”] !! “User to logout does not exist"

David.

> On 28 Jun 2017, at 22:30, Erica Sadun via swift-evolution 
>  wrote:
> 
> Based on the feedback on this thread, I'm coming to the following conclusions:
> 
> `!!` sends the right semantic message. "Unwrap or die" is an unsafe 
> operation. It is based on `!`, the unsafe forced unwrap operator, and not on 
> `??`, the safe fallback nil-coalescing operator. Its symbology should 
> therefore follow `!` and not `?`. 
> 
> The `!!` operator should follow the same semantics as 
> `Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:
> 
> > "The unsafelyUnwrapped property provides the same value as the forced 
> > unwrap operator (postfix !). However, in optimized builds (-O), no check is 
> > performed to ensure that the current instance actually has a value. 
> > Accessing this property in the case of a nil value is a serious programming 
> > error and could lead to undefined behavior or a runtime error."
> 
> By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
>  
> 
> 
> > "Logic failures are intended to be handled by fixing the code. It means 
> > checks of logic failures can be removed if the code is tested enough.
> Actually checks of logic failures for various operations, `!`, `array[i]`, 
> `&+` and so on, are designed and implemented to be removed
> when we use `-Ounchecked`. It is useful for heavy computation like image 
> processing and machine learning in which overhead of those checks is not 
> permissible."
> 
> The right hand side should use a string (or more properly a string 
> autoclosure) in preference to using a `Never` bottom type or a `() -> Never` 
> closure. A string provides the cleanest user experience, and allows the 
> greatest degree of self-documentation. 
> 
> - A string is cleaner and more readable to type. It respects DRY, and avoids 
> using *both* the operator and the call to `fatalError` or 
> `preconditionFailure` to signal an unsafe condition:
> `let last = array.last !! “Array guaranteed non-empty" // readable`
> than: 
> `let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
> redundant, violates DRY`
> 
> - A string allows the operator *itself* to unsafely fail, just as the unary 
> version of `!` does now. It does this with additional feedback to the 
> developer during testing, code reading, and code maintenance. The string 
> provides a self-auditing in-line annotation of the reason why the forced 
> unwrap has been well considered, using a language construct to support this.
> 
> - A string disallows a potentiall

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

That is plainly contrary to what the proposal says. It is to be sugar for a
string argument to fatalError, which would be read: "x, which fails iff y."
On Wed, Jun 28, 2017 at 23:35 Paul Cantrell  wrote:

> On Jun 28, 2017, at 10:49 PM, Xiaodi Wu  wrote:
>
> On Wed, Jun 28, 2017 at 10:33 PM, Paul Cantrell 
> wrote:
>
>>
>> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu  wrote:
>>
>> On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell > > wrote:
>>
>>>
>>> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> I would like to see an example where this string plausibly makes the
>>> difference between having to hunt down the code and not have to do so. I do
>>> not believe that "array must not be empty" or "array guaranteed non-empty"
>>> is such an example, and I cannot myself imagine another scenario where it
>>> would make such a difference.
>>>
>>>
>>> You needn’t imagine. There was one up-thread:
>>>
>>>   let paramData = params.data(using: String.Encoding.ascii)!
>>>
>>> Huh? Why is force unwrap safe here? OK, the code plainly says the author
>>> thinks that `params` must already be ASCII, but why is that a safe
>>> assumption? What reasoning lead to that? What other sections of the code
>>> does that reasoning depend on? If we get a crash on this line of code, what
>>> chain of assumptions should we follow to discover the change that broke the
>>> original author’s reasoning behind the force unwrap?
>>>
>>> This is a job for a comment:
>>>
>>>   let paramData = params.data(using: String.Encoding.ascii)!  // params
>>>  is URL-escaped, thus already ASCII
>>>
>>> Aha, it’s URL escaped.
>>>
>>> That comment does not repeat information already stated in the code
>>> itself. It does what any good comment does: it explains intent, context,
>>> and rationale. It doesn’t restate _what_, but rather explains _why_.
>>>
>>> For those who appreciate comments like that, this proposal simply allows
>>> them to surface at runtime:
>>>
>>>   let paramData = params.data(using: String.Encoding.ascii) !! "params
>>>  is URL-escaped, thus already ASCII"
>>>
>>> And those who see no value in such a runtime message — and thus likely
>>> also see no value such a comment — are free not to use either.
>>>
>>
>> If this is the most convincing example, then I'd actually be adamantly
>> _against_ such an operator (where now I'm merely skeptical and would like
>> to see evidence of usefulness). This example is, quite simply, _wrong_.
>> Here's why:
>>
>> First, if force unwrapping fails, the message should explain why it
>> failed: the reason why it failed is _not_ because it's URL-escaped and
>> _not_ because it's ASCII, but rather because it's **not** ASCII.
>>
>>
>> Fine, then:
>>
>> let paramData = params.data(using: String.Encoding.ascii) !!
>> “params must be URL-escaped, and thus ASCII"
>>
>> …or format the runtime message to fit that style of phrasing:
>>
>> fatal error: unexpectedly found nil while unwrapping an Optional value
>> Failing underlying assumption:
>> params is URL-escaped, thus already ASCII
>> Current stack trace:
>> …
>>
>> Second, even supposing the wording were fixed, it's at best not more
>> useful than `!` and at worst misleading.
>>
>> …
>>
>> If the error message is "params not URL-escaped," then it's misleading,
>> as that's not at all what the LHS is actually asserting: it can be
>> unwrapped *whether or not* it's URL-escaped and it only matters that it's
>> ASCII.
>>
>>
>> Yes, of _course_ it’s not what the LHS is actually asserting. That is
>> precisely the point of having a message. There is pertinent information not
>> already present in the code.
>>
>
> See below.
>
>
>> The message describes an invariant not captured by the type system. In
>> other words, the author of this code believes they have guaranteed
>> something that the compiler itself cannot check. Thus this statement is
>> exactly backwards:
>>
>> You **absolutely cannot** proceed from this point in the code assuming
>> that `paramData` is a URL-escaped string.
>>
>>
>> The author of this code is telling you they have _already_ proceeded from
>> this point assuming that `paramData` is URL-escaped.
>>
>
> No, the author proceeded from a previous point assuming that `params` is
> URL-escaped. The act of unwrapping does not demarcate the transition
> between where `params` is assumed to be URL-escaped and where it is not.
>
>
> Well duh. But that’s not what the message conveys.
>
> Read x !! y as “x! /* which is guaranteed to succeed because y */”.
>
> P
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Paul Cantrell via swift-evolution]

> On Jun 28, 2017, at 10:49 PM, Xiaodi Wu  wrote:
> 
> On Wed, Jun 28, 2017 at 10:33 PM, Paul Cantrell  > wrote:
> 
>> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu > > wrote:
>> 
>> On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell > > wrote:
>> 
>>> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I would like to see an example where this string plausibly makes the 
>>> difference between having to hunt down the code and not have to do so. I do 
>>> not believe that "array must not be empty" or "array guaranteed non-empty" 
>>> is such an example, and I cannot myself imagine another scenario where it 
>>> would make such a difference.
>> 
>> You needn’t imagine. There was one up-thread:
>> 
>>   let paramData = params.data(using: String.Encoding.ascii)!
>> 
>> Huh? Why is force unwrap safe here? OK, the code plainly says the author 
>> thinks that `params` must already be ASCII, but why is that a safe 
>> assumption? What reasoning lead to that? What other sections of the code 
>> does that reasoning depend on? If we get a crash on this line of code, what 
>> chain of assumptions should we follow to discover the change that broke the 
>> original author’s reasoning behind the force unwrap?
>> 
>> This is a job for a comment:
>> 
>>   let paramData = params.data(using: String.Encoding.ascii)!  // params is 
>> URL-escaped, thus already ASCII
>> 
>> Aha, it’s URL escaped.
>> 
>> That comment does not repeat information already stated in the code itself. 
>> It does what any good comment does: it explains intent, context, and 
>> rationale. It doesn’t restate _what_, but rather explains _why_.
>> 
>> For those who appreciate comments like that, this proposal simply allows 
>> them to surface at runtime:
>> 
>>   let paramData = params.data(using: String.Encoding.ascii) !! "params is 
>> URL-escaped, thus already ASCII"
>> 
>> And those who see no value in such a runtime message — and thus likely also 
>> see no value such a comment — are free not to use either.
>> 
>> If this is the most convincing example, then I'd actually be adamantly 
>> _against_ such an operator (where now I'm merely skeptical and would like to 
>> see evidence of usefulness). This example is, quite simply, _wrong_. Here's 
>> why:
>> 
>> First, if force unwrapping fails, the message should explain why it failed: 
>> the reason why it failed is _not_ because it's URL-escaped and _not_ because 
>> it's ASCII, but rather because it's **not** ASCII.
> 
> Fine, then:
> 
> let paramData = params.data(using: String.Encoding.ascii) !! “params must 
> be URL-escaped, and thus ASCII"
> 
> …or format the runtime message to fit that style of phrasing:
> 
> fatal error: unexpectedly found nil while unwrapping an Optional value
> Failing underlying assumption:
> params is URL-escaped, thus already ASCII
> Current stack trace:
> …
> 
>> Second, even supposing the wording were fixed, it's at best not more useful 
>> than `!` and at worst misleading.
> …
>> If the error message is "params not URL-escaped," then it's misleading, as 
>> that's not at all what the LHS is actually asserting: it can be unwrapped 
>> *whether or not* it's URL-escaped and it only matters that it's ASCII.
> 
> Yes, of _course_ it’s not what the LHS is actually asserting. That is 
> precisely the point of having a message. There is pertinent information not 
> already present in the code.
> 
> See below.
>  
> The message describes an invariant not captured by the type system. In other 
> words, the author of this code believes they have guaranteed something that 
> the compiler itself cannot check. Thus this statement is exactly backwards:
> 
>> You **absolutely cannot** proceed from this point in the code assuming that 
>> `paramData` is a URL-escaped string.
> 
> The author of this code is telling you they have _already_ proceeded from 
> this point assuming that `paramData` is URL-escaped.
> 
> No, the author proceeded from a previous point assuming that `params` is 
> URL-escaped. The act of unwrapping does not demarcate the transition between 
> where `params` is assumed to be URL-escaped and where it is not.

Well duh. But that’s not what the message conveys.

Read x !! y as “x! /* which is guaranteed to succeed because y */”.

P

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 10:33 PM, Paul Cantrell  wrote:

>
> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu  wrote:
>
> On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell 
> wrote:
>
>>
>> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I would like to see an example where this string plausibly makes the
>> difference between having to hunt down the code and not have to do so. I do
>> not believe that "array must not be empty" or "array guaranteed non-empty"
>> is such an example, and I cannot myself imagine another scenario where it
>> would make such a difference.
>>
>>
>> You needn’t imagine. There was one up-thread:
>>
>>   let paramData = params.data(using: String.Encoding.ascii)!
>>
>> Huh? Why is force unwrap safe here? OK, the code plainly says the author
>> thinks that `params` must already be ASCII, but why is that a safe
>> assumption? What reasoning lead to that? What other sections of the code
>> does that reasoning depend on? If we get a crash on this line of code, what
>> chain of assumptions should we follow to discover the change that broke the
>> original author’s reasoning behind the force unwrap?
>>
>> This is a job for a comment:
>>
>>   let paramData = params.data(using: String.Encoding.ascii)!  // params
>>  is URL-escaped, thus already ASCII
>>
>> Aha, it’s URL escaped.
>>
>> That comment does not repeat information already stated in the code
>> itself. It does what any good comment does: it explains intent, context,
>> and rationale. It doesn’t restate _what_, but rather explains _why_.
>>
>> For those who appreciate comments like that, this proposal simply allows
>> them to surface at runtime:
>>
>>   let paramData = params.data(using: String.Encoding.ascii) !! "params
>>  is URL-escaped, thus already ASCII"
>>
>> And those who see no value in such a runtime message — and thus likely
>> also see no value such a comment — are free not to use either.
>>
>
> If this is the most convincing example, then I'd actually be adamantly
> _against_ such an operator (where now I'm merely skeptical and would like
> to see evidence of usefulness). This example is, quite simply, _wrong_.
> Here's why:
>
> First, if force unwrapping fails, the message should explain why it
> failed: the reason why it failed is _not_ because it's URL-escaped and
> _not_ because it's ASCII, but rather because it's **not** ASCII.
>
>
> Fine, then:
>
> let paramData = params.data(using: String.Encoding.ascii) !!
> “params must be URL-escaped, and thus ASCII"
>
> …or format the runtime message to fit that style of phrasing:
>
> fatal error: unexpectedly found nil while unwrapping an Optional value
> Failing underlying assumption:
> params is URL-escaped, thus already ASCII
> Current stack trace:
> …
>
> Second, even supposing the wording were fixed, it's at best not more
> useful than `!` and at worst misleading.
>
> …
>
> If the error message is "params not URL-escaped," then it's misleading, as
> that's not at all what the LHS is actually asserting: it can be unwrapped
> *whether or not* it's URL-escaped and it only matters that it's ASCII.
>
>
> Yes, of _course_ it’s not what the LHS is actually asserting. That is
> precisely the point of having a message. There is pertinent information not
> already present in the code.
>

See below.


> The message describes an invariant not captured by the type system. In
> other words, the author of this code believes they have guaranteed
> something that the compiler itself cannot check. Thus this statement is
> exactly backwards:
>
> You **absolutely cannot** proceed from this point in the code assuming
> that `paramData` is a URL-escaped string.
>
>
> The author of this code is telling you they have _already_ proceeded from
> this point assuming that `paramData` is URL-escaped.
>

No, the author proceeded from a previous point assuming that `params` is
URL-escaped. The act of unwrapping does not demarcate the transition
between where `params` is assumed to be URL-escaped and where it is not.
Execution can proceed past this point even if `params` is *not* URL-escaped.

They may have assumed wrong, but even if they did, this insight into the
> developer’s thinking is valuable.
>
> Indeed, though we try to minimize it, there will inevitably be code that
> relies on assumptions the compiler cannot check. That is why the language
> has ! in the first place. Those uncheckable assumptions are not always
> self-evident. This is why languages provide comments and diagnostic
> messages.
>
> Literalism nit-picking over the semantics of the RHS deliberately miss the
> original argument: the RHS is information-bearing.
>

_Of course_ the goal is to nail down the semantics of the RHS. It's a
proposal for an infix operator, for which the semantics of the LHS are not
in dispute. What else is there to talk about?
___
swift-evolution mailing list
swift-evolution@swift.org
htt

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 9:50 PM, Xiaodi Wu  wrote:

> On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell 
> wrote:
>
>>
>> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I would like to see an example where this string plausibly makes the
>> difference between having to hunt down the code and not have to do so. I do
>> not believe that "array must not be empty" or "array guaranteed non-empty"
>> is such an example, and I cannot myself imagine another scenario where it
>> would make such a difference.
>>
>>
>> You needn’t imagine. There was one up-thread:
>>
>>   let paramData = params.data(using: String.Encoding.ascii)!
>>
>> Huh? Why is force unwrap safe here? OK, the code plainly says the author
>> thinks that `params` must already be ASCII, but why is that a safe
>> assumption? What reasoning lead to that? What other sections of the code
>> does that reasoning depend on? If we get a crash on this line of code, what
>> chain of assumptions should we follow to discover the change that broke the
>> original author’s reasoning behind the force unwrap?
>>
>> This is a job for a comment:
>>
>>   let paramData = params.data(using: String.Encoding.ascii)!  // params
>>  is URL-escaped, thus already ASCII
>>
>> Aha, it’s URL escaped.
>>
>> That comment does not repeat information already stated in the code
>> itself. It does what any good comment does: it explains intent, context,
>> and rationale. It doesn’t restate _what_, but rather explains _why_.
>>
>> For those who appreciate comments like that, this proposal simply allows
>> them to surface at runtime:
>>
>>   let paramData = params.data(using: String.Encoding.ascii) !! "params
>>  is URL-escaped, thus already ASCII"
>>
>> And those who see no value in such a runtime message — and thus likely
>> also see no value such a comment — are free not to use either.
>>
>
> If this is the most convincing example, then I'd actually be adamantly
> _against_ such an operator (where now I'm merely skeptical and would like
> to see evidence of usefulness). This example is, quite simply, _wrong_.
> Here's why:
>
> First, if force unwrapping fails, the message should explain why it
> failed: the reason why it failed is _not_ because it's URL-escaped and
> _not_ because it's ASCII, but rather because it's **not** ASCII.
>
> Second, even supposing the wording were fixed, it's at best not more
> useful than `!` and at worst misleading. If the error message is "params
> not ASCII-encoded" then it restates the code itself. If the error message
> is "params not URL-escaped," then it's misleading, as that's not at all
> what the LHS is actually asserting: it can be unwrapped *whether or not*
> it's URL-escaped and it only matters that it's ASCII. You **absolutely
> cannot** proceed from this point in the code assuming that `paramData` is a
> URL-escaped string.
>

At the risk of belaboring the point, allow me to develop this intuition
further. The second argument in a precondition is classically phrased "X
must be Y" or "X is not Y," and it serves two purposes (as I understand
it). If the precondition fails, then the reader understands that it is
because X is not Y. If the precondition succeeds, the reader is assured
that the precondition has tested that X is in fact Y.

Two uses have been advanced for the RHS of the proposed operator. The first
is, in the case of failure, to explain the failure without requiring
surrounding code context. The second is to explain to the reader, in the
context of the code, why success should be assured. But, this does not
imply that the underlying reason why success is assured is in turn also
true if the force unwrapping operation succeeds.

_The only error message_ that satisfies both of the purposes of a
precondition message in the case of a force unwrap is "X is not nil." In
your example, "params must be URL-escaped" cannot fulfill both of these
uses, because successful unwrapping is not preconditioned on params being
in fact URL-escaped. OTOH, "params must be ASCII-encoded" is not necessary
as a message because it is implied in the meaning of `!`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 10:18 PM, Alan Westbrook 
wrote:

>
> On Jun 28, 2017, at 8:02 PM, Xiaodi Wu  wrote:
>
> I reject both these notions. Having seen the examples given above, I'm now
> leaning towards the conclusion that there is nothing in the way of
> explanation in a string that can usefully elaborate upon the very
> unambiguous statement that is a force unwrap.
>
>
> That the functionality exists to provide messages with fatal errors is an
> indication that they do have some utility.
>

Not at all. A message is required for `fatalError` simply to explain _what_
the error is. By contrast, it has already been conceded that there is
absolutely no confusion as to _what_ the error is in the case of a failed
force-unwrap. Rather, as Ben Cohen argued above, the idea behind this
proposal is that it is useful to explain the "why"--on the premise that
there is some "why" which is not deducible from the "what." My argument is
that there is no suitable "why" which can be suitably expressed in a
sugared form of a fatalError string argument.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Paul Cantrell via swift-evolution]

> On Jun 28, 2017, at 9:50 PM, Xiaodi Wu  wrote:
> 
> On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell  > wrote:
> 
>> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I would like to see an example where this string plausibly makes the 
>> difference between having to hunt down the code and not have to do so. I do 
>> not believe that "array must not be empty" or "array guaranteed non-empty" 
>> is such an example, and I cannot myself imagine another scenario where it 
>> would make such a difference.
> 
> You needn’t imagine. There was one up-thread:
> 
>   let paramData = params.data(using: String.Encoding.ascii)!
> 
> Huh? Why is force unwrap safe here? OK, the code plainly says the author 
> thinks that `params` must already be ASCII, but why is that a safe 
> assumption? What reasoning lead to that? What other sections of the code does 
> that reasoning depend on? If we get a crash on this line of code, what chain 
> of assumptions should we follow to discover the change that broke the 
> original author’s reasoning behind the force unwrap?
> 
> This is a job for a comment:
> 
>   let paramData = params.data(using: String.Encoding.ascii)!  // params is 
> URL-escaped, thus already ASCII
> 
> Aha, it’s URL escaped.
> 
> That comment does not repeat information already stated in the code itself. 
> It does what any good comment does: it explains intent, context, and 
> rationale. It doesn’t restate _what_, but rather explains _why_.
> 
> For those who appreciate comments like that, this proposal simply allows them 
> to surface at runtime:
> 
>   let paramData = params.data(using: String.Encoding.ascii) !! "params is 
> URL-escaped, thus already ASCII"
> 
> And those who see no value in such a runtime message — and thus likely also 
> see no value such a comment — are free not to use either.
> 
> If this is the most convincing example, then I'd actually be adamantly 
> _against_ such an operator (where now I'm merely skeptical and would like to 
> see evidence of usefulness). This example is, quite simply, _wrong_. Here's 
> why:
> 
> First, if force unwrapping fails, the message should explain why it failed: 
> the reason why it failed is _not_ because it's URL-escaped and _not_ because 
> it's ASCII, but rather because it's **not** ASCII.

Fine, then:

let paramData = params.data(using: String.Encoding.ascii) !! “params must 
be URL-escaped, and thus ASCII"

…or format the runtime message to fit that style of phrasing:

fatal error: unexpectedly found nil while unwrapping an Optional value
Failing underlying assumption:
params is URL-escaped, thus already ASCII
Current stack trace:
…

> Second, even supposing the wording were fixed, it's at best not more useful 
> than `!` and at worst misleading.
…
> If the error message is "params not URL-escaped," then it's misleading, as 
> that's not at all what the LHS is actually asserting: it can be unwrapped 
> *whether or not* it's URL-escaped and it only matters that it's ASCII.

Yes, of _course_ it’s not what the LHS is actually asserting. That is precisely 
the point of having a message. There is pertinent information not already 
present in the code.

The message describes an invariant not captured by the type system. In other 
words, the author of this code believes they have guaranteed something that the 
compiler itself cannot check. Thus this statement is exactly backwards:

> You **absolutely cannot** proceed from this point in the code assuming that 
> `paramData` is a URL-escaped string.

The author of this code is telling you they have _already_ proceeded from this 
point assuming that `paramData` is URL-escaped. They may have assumed wrong, 
but even if they did, this insight into the developer’s thinking is valuable.

Indeed, though we try to minimize it, there will inevitably be code that relies 
on assumptions the compiler cannot check. That is why the language has ! in the 
first place. Those uncheckable assumptions are not always self-evident. This is 
why languages provide comments and diagnostic messages.

Literalism nit-picking over the semantics of the RHS deliberately miss the 
original argument: the RHS is information-bearing.

Cheers, P

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Alan Westbrook via swift-evolution]

> On Jun 28, 2017, at 8:02 PM, Xiaodi Wu  wrote:
> 
> I reject both these notions. Having seen the examples given above, I'm now 
> leaning towards the conclusion that there is nothing in the way of 
> explanation in a string that can usefully elaborate upon the very unambiguous 
> statement that is a force unwrap.

That the functionality exists to provide messages with fatal errors is an 
indication that they do have some utility.

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 9:50 PM, Alan Westbrook 
wrote:

>
> On Jun 28, 2017, at 6:38 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry, I fail to see how either wording enhances the expression of why
> this operation is taking place. The entire explanation seems self-evident
> to me in `!`.
>
>
> It may not be though. How many times have you seen a force unwrap and
> immediately thought the programmer to just be lazy, or new to Swift?
>

Never. (Now ask me what I immediately think of programmers who assert that
force unwrapping is a code smell...)

The !! syntax proposal at least makes these forces clearly an intentional
> and thought out endeavor.
>

As I wrote, if that's the objection, then we might as well simply coin a
new operator spelled `!!!`, identical in behavior to `!` but called the
"intentional and thought-out force-unwrapping operator." Equally, it'd be
an argument to retire postfix `!` and to introduce an infix `!` which
mandates an explanation.

This is actually, on rethink, a diametrically opposite argument to the
first one posed by Ben Cohen. That argument claims that there's sometimes a
need to explain the context of a force-unwrap with a human-readable
rationale; just like there's room for a one-argument precondition and a
two-argument precondition, there should be room for a two-argument
force-unwrap. Here, there's a claim that people assume all force-unwrapping
to be poorly thought out without a human-readable rationale. This is,
again, really an argument that there is no good unannotated force-unwrap.

I reject both these notions. Having seen the examples given above, I'm now
leaning towards the conclusion that there is nothing in the way of
explanation in a string that can usefully elaborate upon the very
unambiguous statement that is a force unwrap.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell 
wrote:

>
> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I would like to see an example where this string plausibly makes the
> difference between having to hunt down the code and not have to do so. I do
> not believe that "array must not be empty" or "array guaranteed non-empty"
> is such an example, and I cannot myself imagine another scenario where it
> would make such a difference.
>
>
> You needn’t imagine. There was one up-thread:
>
>   let paramData = params.data(using: String.Encoding.ascii)!
>
> Huh? Why is force unwrap safe here? OK, the code plainly says the author
> thinks that `params` must already be ASCII, but why is that a safe
> assumption? What reasoning lead to that? What other sections of the code
> does that reasoning depend on? If we get a crash on this line of code, what
> chain of assumptions should we follow to discover the change that broke the
> original author’s reasoning behind the force unwrap?
>
> This is a job for a comment:
>
>   let paramData = params.data(using: String.Encoding.ascii)!  // params
>  is URL-escaped, thus already ASCII
>
> Aha, it’s URL escaped.
>
> That comment does not repeat information already stated in the code
> itself. It does what any good comment does: it explains intent, context,
> and rationale. It doesn’t restate _what_, but rather explains _why_.
>
> For those who appreciate comments like that, this proposal simply allows
> them to surface at runtime:
>
>   let paramData = params.data(using: String.Encoding.ascii) !! "params is 
> URL-escaped,
> thus already ASCII"
>
> And those who see no value in such a runtime message — and thus likely
> also see no value such a comment — are free not to use either.
>

If this is the most convincing example, then I'd actually be adamantly
_against_ such an operator (where now I'm merely skeptical and would like
to see evidence of usefulness). This example is, quite simply, _wrong_.
Here's why:

First, if force unwrapping fails, the message should explain why it failed:
the reason why it failed is _not_ because it's URL-escaped and _not_
because it's ASCII, but rather because it's **not** ASCII.

Second, even supposing the wording were fixed, it's at best not more useful
than `!` and at worst misleading. If the error message is "params not
ASCII-encoded" then it restates the code itself. If the error message is
"params not URL-escaped," then it's misleading, as that's not at all what
the LHS is actually asserting: it can be unwrapped *whether or not* it's
URL-escaped and it only matters that it's ASCII. You **absolutely cannot**
proceed from this point in the code assuming that `paramData` is a
URL-escaped string.



> Cheers,
>
> Paul
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Alan Westbrook via swift-evolution]

> On Jun 28, 2017, at 6:38 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Sorry, I fail to see how either wording enhances the expression of why this 
> operation is taking place. The entire explanation seems self-evident to me in 
> `!`.

It may not be though. How many times have you seen a force unwrap and 
immediately thought the programmer to just be lazy, or new to Swift?

The !! syntax proposal at least makes these forces clearly an intentional and 
thought out endeavor.

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Paul Cantrell via swift-evolution]

> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> I would like to see an example where this string plausibly makes the 
> difference between having to hunt down the code and not have to do so. I do 
> not believe that "array must not be empty" or "array guaranteed non-empty" is 
> such an example, and I cannot myself imagine another scenario where it would 
> make such a difference.

You needn’t imagine. There was one up-thread:

  let paramData = params.data(using: String.Encoding.ascii)!

Huh? Why is force unwrap safe here? OK, the code plainly says the author thinks 
that `params` must already be ASCII, but why is that a safe assumption? What 
reasoning lead to that? What other sections of the code does that reasoning 
depend on? If we get a crash on this line of code, what chain of assumptions 
should we follow to discover the change that broke the original author’s 
reasoning behind the force unwrap?

This is a job for a comment:

  let paramData = params.data(using: String.Encoding.ascii)!  // params is 
URL-escaped, thus already ASCII

Aha, it’s URL escaped.

That comment does not repeat information already stated in the code itself. It 
does what any good comment does: it explains intent, context, and rationale. It 
doesn’t restate _what_, but rather explains _why_.

For those who appreciate comments like that, this proposal simply allows them 
to surface at runtime:

  let paramData = params.data(using: String.Encoding.ascii) !! "params is 
URL-escaped, thus already ASCII"

And those who see no value in such a runtime message — and thus likely also see 
no value such a comment — are free not to use either.

Cheers,

Paul

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Ben Cohen via swift-evolution]

> On Jun 28, 2017, at 6:32 PM, Xiaodi Wu  wrote:
> 
>  the reason why a function would return nil _are intended to be obvious, per 
> the design rationale given in Swift project documents_.

The reason .last returns nil is obvious. But it doesn’t tell you anything about 
why the array itself should be non-empty at this point in the code.

> I do not believe that "array must not be empty" or "array guaranteed 
> non-empty" is such an example, and I cannot myself imagine another scenario 
> where it would make such a difference.


As the screener of a non-zero number of radars resulting from unwrapped nils, I 
would certainly appreciate more use of guard let x = x else { 
fatalError(“explanation”) } and hope that !! would encourage it.


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 8:13 PM, Erica Sadun  wrote:

>
> On Jun 28, 2017, at 6:26 PM, Xiaodi Wu  wrote:
>
> On Wed, Jun 28, 2017 at 5:05 PM, ilya via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> One could, for example, extend the existing* documentation markup sign*
>> *///* to pick up text as force unwrap messages:
>>
>> `let last = array.last! /// Array guaranteed non-empty`
>>
>
> I did not call this out initially, but I feel like this is an important
> point to address:
>
> In the initial example, repeated here in largely identical form, the
> desired comment is "array must be non-empty." In what way does that provide
> more information than a bare `!`?
>
>
> That is why I changed it back to my "*guarantee*" version when replying:
>
> guard !array.isEmpty else { ... }
> /* ... */
> let finalElement  = array.last !! "Array guaranteed non-empty"
>
>
> The expected unwrap behavior is clear and audited, even when other code
> appears between the guard statement and the explained forced unwrap.
>
> As you point out, it's senseless to annotate a logical assertion known to
> be true ("must be non-empty") *unless that annotation enhances the
> expression of why and how this otherwise dangerous operation is taking
> place*. That explanation forms the mission statement of the `!!` operator.
>

Sorry, I fail to see how either wording enhances the expression of why this
operation is taking place. The entire explanation seems self-evident to me
in `!`.


> By explaining, the `!!` operator differs from the direct use of `!`. It
> explains a fact known to hold true that allows the lhs to safely unwrap. It
> provides this in a way that is succinct and readable. It naturally moves
> with the line of code it is part of. The adoption of `!!` has already
> broadly been integrated into any number idiomatic libraries. Coders have
> done so to differentiate an *audited known fact* from the stray `!`,
> which may or may not be followed by a comment.
>

_Every_ use of `!` is an assertion that it is an audited known fact that
the operand is not nil. What I'm saying is that, so far in this
conversation, I have seen no example where any other known fact on the RHS
of your proposed operator is not trivially deducible from the built-in
known fact signified by `!` itself.

One last point: it is not the mission of document comments to provide any
> role beyond annotation. They are not there to guarantee preconditions,
> assertions, or any other behavioral contracts. They merely document.
>
> -- Erica
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 8:18 PM, Ben Cohen  wrote:

>
> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In the initial example, repeated here in largely identical form, the
> desired comment is "array must be non-empty." In what way does that provide
> more information than a bare `!`?
>
>
> By the same token, why does precondition have an optional string? Why
> would you ever want to write more than:
>
> precondition(!array.isEmpty)
>
> It’s self evident – the array must not be empty! Why the second argument?
>

In the case of `!array.isEmpty`, I would never use the second argument
precisely because that condition is self-documenting. As to the larger
question of why `precondition` is overloaded to take a second argument, my
understanding--reflected in how I use it--is that it is useful when the
meaning of the precondition is less than glanceable and cannot (without
significant effort on the part of the reader) reveal a human-readable
explanation as to _why_ the precondition might fail. However, as I
mentioned, the act of unwrapping an optional and the reason why a function
would return nil _are intended to be obvious, per the design rationale
given in Swift project documents_.


> Because you might want a meaningful string to be output when the app
> traps. And it gives you somewhere to document *why* it mustn’t be empty –
> the explanation for the precondition rather than the precondition itself.
> Similarly, when your app traps because of an unwrapped nil, it’s desirable
> to get some output in your debug console telling you why straight away,
> rather than have to hunt down the code, read the line that failed, then
> read the context around the line, to understand the reason. This is even
> more important if you didn’t write this code yourself.
>

I would like to see an example where this string plausibly makes the
difference between having to hunt down the code and not have to do so. I do
not believe that "array must not be empty" or "array guaranteed non-empty"
is such an example, and I cannot myself imagine another scenario where it
would make such a difference.


> Finally, there’s a woolier justification: there’s an often-touted
> misconception out there that force unwraps are bad, that they were only
> created to accommodate legacy apps, and that force-unwrapping is always bad
> and you should never do it. This isn’t true – there are many good reasons
> to use force unwrap (though if you reaching for it constantly it’s a bad
> sign). Force-unwrapping is often better than just whacking in a default
> value or optional chaining when the presence of nil would indicate a
> serious failure. Introduction of the `!!` operator could help
> endorse/encourage the use of “thoughtful” force-unwrapping, which often
> comes with a comment of the reasoning why it’s safe (of why the array can’t
> be empty at this point, not just that it is empty). And if you’re going to
> write a comment, why not make that comment useful for debugging at the same
> time.
>
> In cases where it’s really not necessary, ! would remain just like, when
> you’re not really too fussed, you can leave off the string from a
> precondition.
>

I am not sure this second argument is a winning one, in that it does
nothing to convince me that the RHS string is necessary. If the issue to be
addressed is that `!` is used too lightly and without thought, an equally
optimal result would be achieved by devising a new postfix operator `!!!`,
to be named the "thoughtful force-unwrapping operator," which is purely a
synonym for `!`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

On Jun 28, 2017, at 6:43 PM, Alan Westbrook via swift-evolution 
 wrote:
> 
> 
>> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In the initial example, repeated here in largely identical form, the desired 
>> comment is "array must be non-empty." In what way does that provide more 
>> information than a bare `!`?
> 
> I’m going to second this sentiment with the feeling that the message is 
> seemingly redundant. It feels akin to the comment in this line of code:
> 
> let value = 1 // This value is set to 1
> 
> On an error, one gets the trap with the optional unwrapped message, and goes 
> to the code where they see what is being forced by assumption.
> 
> Does the message spelling out the code in natural language help?
> 
> Alan

I have replied to another email but will repeat the point here: The proposed 
`!!` operator differs from the direct use of `!` in that it explains a fact 
known to hold true, allowing the lhs to safely unwrap. 

The alternatives are:

* forced unwrap -- comments do not transfer to runtime, which leads coders to 
use:
* using guard with fatalError -- the !! operator provides an elegant sugared 
shortcut for this common code

-- E


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Ben Cohen via swift-evolution]

> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> In the initial example, repeated here in largely identical form, the desired 
> comment is "array must be non-empty." In what way does that provide more 
> information than a bare `!`?
> 

By the same token, why does precondition have an optional string? Why would you 
ever want to write more than:

precondition(!array.isEmpty)

It’s self evident – the array must not be empty! Why the second argument? 

Because you might want a meaningful string to be output when the app traps. And 
it gives you somewhere to document why it mustn’t be empty – the explanation 
for the precondition rather than the precondition itself. Similarly, when your 
app traps because of an unwrapped nil, it’s desirable to get some output in 
your debug console telling you why straight away, rather than have to hunt down 
the code, read the line that failed, then read the context around the line, to 
understand the reason. This is even more important if you didn’t write this 
code yourself.

Finally, there’s a woolier justification: there’s an often-touted misconception 
out there that force unwraps are bad, that they were only created to 
accommodate legacy apps, and that force-unwrapping is always bad and you should 
never do it. This isn’t true – there are many good reasons to use force unwrap 
(though if you reaching for it constantly it’s a bad sign). Force-unwrapping is 
often better than just whacking in a default value or optional chaining when 
the presence of nil would indicate a serious failure. Introduction of the `!!` 
operator could help endorse/encourage the use of “thoughtful” force-unwrapping, 
which often comes with a comment of the reasoning why it’s safe (of why the 
array can’t be empty at this point, not just that it is empty). And if you’re 
going to write a comment, why not make that comment useful for debugging at the 
same time.

In cases where it’s really not necessary, ! would remain just like, when you’re 
not really too fussed, you can leave off the string from a precondition.


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

> On Jun 28, 2017, at 6:26 PM, Xiaodi Wu  wrote:
> 
> On Wed, Jun 28, 2017 at 5:05 PM, ilya via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> One could, for example, extend the existing documentation markup sign /// to 
> pick up text as force unwrap messages:
> 
> `let last = array.last! /// Array guaranteed non-empty`
> 
> I did not call this out initially, but I feel like this is an important point 
> to address:
> 
> In the initial example, repeated here in largely identical form, the desired 
> comment is "array must be non-empty." In what way does that provide more 
> information than a bare `!`?

That is why I changed it back to my "guarantee" version when replying:

guard !array.isEmpty else { ... }
/* ... */
let finalElement  = array.last !! "Array guaranteed non-empty"

The expected unwrap behavior is clear and audited, even when other code appears 
between the guard statement and the explained forced unwrap. 

As you point out, it's senseless to annotate a logical assertion known to be 
true ("must be non-empty") unless that annotation enhances the expression of 
why and how this otherwise dangerous operation is taking place. That 
explanation forms the mission statement of the `!!` operator.

By explaining, the `!!` operator differs from the direct use of `!`. It 
explains a fact known to hold true that allows the lhs to safely unwrap. It 
provides this in a way that is succinct and readable. It naturally moves with 
the line of code it is part of. The adoption of `!!` has already broadly been 
integrated into any number idiomatic libraries. Coders have done so to 
differentiate an audited known fact from the stray `!`, which may or may not be 
followed by a comment.

One last point: it is not the mission of document comments to provide any role 
beyond annotation. They are not there to guarantee preconditions, assertions, 
or any other behavioral contracts. They merely document.

-- Erica



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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Alan Westbrook via swift-evolution]

> On Jun 28, 2017, at 5:43 PM, Alan Westbrook via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In the initial example, repeated here in largely identical form, the desired 
>> comment is "array must be non-empty." In what way does that provide more 
>> information than a bare `!`?
> 
> I’m going to second this sentiment with the feeling that the message is 
> seemingly redundant. It feels akin to the comment in this line of code:
> 
> let value = 1 // This value is set to 1
> 
> On an error, one gets the trap with the optional unwrapped message, and goes 
> to the code where they see what is being forced by assumption.
> 
> Does the message spelling out the code in natural language help?


Perhaps I am misunderstanding, we should probably not focus on the content of 
the message, but rather that it exists at all.

Assuming that the fatal-error-with-message is useful, is it important to have a 
shorthand for this pattern built into the language?

If we think so, I believe the original proposal is the best solution so far, 
given the arguments against using ?? fatal…

Alan


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Alan Westbrook via swift-evolution]

> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> In the initial example, repeated here in largely identical form, the desired 
> comment is "array must be non-empty." In what way does that provide more 
> information than a bare `!`?

I’m going to second this sentiment with the feeling that the message is 
seemingly redundant. It feels akin to the comment in this line of code:

let value = 1 // This value is set to 1

On an error, one gets the trap with the optional unwrapped message, and goes to 
the code where they see what is being forced by assumption.

Does the message spelling out the code in natural language help?

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

On Wed, Jun 28, 2017 at 5:05 PM, ilya via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm unconvinced. We already have the perfectly functional "unwrap or die"
> operator, that is, the *force unwrap* *! *operator.
>
> Can it be improved? Definitely. If the developer wants to provide some
> context for a possible fatal error, it would be great for the language to
> give the tools to express it.
>
> Perhaps we can examine a more general problem of improving debugging
> output for symbols and operations. We can already associate some
> information with functions and classes using the documentation markup. Why
> not build on that?
>
> One could, for example, extend the existing* documentation markup sign*
> *///* to pick up text as force unwrap messages:
>
> `let last = array.last! /// Array guaranteed non-empty`
>

I did not call this out initially, but I feel like this is an important
point to address:

In the initial example, repeated here in largely identical form, the
desired comment is "array must be non-empty." In what way does that provide
more information than a bare `!`?

To my mind, when you unwrap an optional, the reason for failure is evident:
you expected some value, but you got no value. Moreover, the document about
error handling design in Swift (available in the GitHub repo) explains that
functions should return nil (vs. throwing) _when there's only one (obvious)
way to fail_. Therefore, when you force-unwrap the subsequent result and
trap, there's been an obvious failure when you expected none. As far as I
can see, the overall logic behind such a design works together to obviate
the need for more explanation when force-unwrapping. The example above
demonstrates this point very well: when there is no last element of an
array, the array must be empty--this is, I'm sure all will agree, plainly
obvious and wisely modeled with an optional--and therefore, if you
encounter a fatal error unwrapping the result, you expected a non-empty
array and instead encountered an empty array.

As a result, I find Ilya's point to be very illuminating that `!` is _the_
force-unwrap-or-die operator. Can someone come up with a more plausible
motivation for an additional operator?


> Best,
> Ilya.
>
> On Wed, Jun 28, 2017 at 11:00 PM Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Based on the feedback on this thread, I'm coming to the following
>> conclusions:
>>
>> `!!` sends the *right semantic message*. "Unwrap or die" is an unsafe
>> operation. It is based on `!`, the unsafe forced unwrap operator, and not
>> on `??`, the safe fallback nil-coalescing operator. Its symbology should
>> therefore follow `!` and not `?`.
>>
>> The `!!` operator should follow the same semantics as `
>> Optional.unsafelyUnwrapped`, which establishes a precedent for this
>> approach:
>>
>> > "*The unsafelyUnwrapped property provides the same value as the forced
>> unwrap operator (postfix !). However, in optimized builds (-O), no check is
>> performed to ensure that the current instance actually has a value.
>> Accessing this property in the case of a nil value is a serious programming
>> error and could lead to undefined behavior or a runtime error.*"
>>
>>
>> By following `Optional.unsafelyUnwrapped`, this approach is consistent
>> with https://github.com/apple/swift/blob/master/docs/
>> ErrorHandlingRationale.rst#logic-failures
>>
>>
>>
>> *> "Logic failures are intended to be handled by fixing the code. It
>> means checks of logic failures can be removed if the code is tested
>> enough.Actually checks of logic failures for various operations,
>> `!`, `array[i]`, `&+` and so on, are designed and implemented to be
>> removedwhen we use `-Ounchecked`. It is useful for heavy computation
>> like image processing and machine learning in which overhead of
>> those checks is not permissible."*
>>
>>
>> The right hand side should use a string (or more properly a string
>> autoclosure) in preference to using a `Never` bottom type or a `() ->
>> Never` closure. A string provides the cleanest user experience, and
>> allows the greatest degree of self-documentation.
>>
>> - A string is cleaner and more readable to type. It respects DRY, and
>> avoids using *both* the operator and the call to `fatalError` or
>> `preconditionFailure` to signal an unsafe condition:
>>
>> `let last = array.last !! “Array guaranteed non-empty" // readable`
>>
>> than:
>>
>> `let last = array.last !! fatalError(“Array guaranteed non-empty”) //
>> redundant, violates DRY`
>>
>> - A string allows the operator **itself** to unsafely fail, just as the
>> unary version of `!` does now. It does this with additional feedback to the
>> developer during testing, code reading, and code maintenance. The string
>> provides a self-auditing in-line annotation of the reason why the forced
>> unwrap has been well considered, using a language construct to support this.
>>
>> - A string disallows a potentially unsafe `Never` call that does not

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jaden Geller via swift-evolution]

I realize that, which is why I’m strongly against this proposal. I could 
potentially be for adding the `??` overload temporarily, but I don’t really 
feel it is necessary either.

> On Jun 28, 2017, at 2:55 PM, Adrian Zubarev  
> wrote:
> 
> Besides all that Never as a bottom type means that you can use fatalError() 
> literally everywhere not only on the RHS of ??.
> 
> func foo(_: Int) {}
> 
> foo(fatalError())
> That said, we can kill our application everywhere we would ever imagine, 
> regardless of whether there is ? or ! operator present somewhere.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 28. Juni 2017 um 23:50:18, Jaden Geller via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> I’m strongly against not using the `??` operator for `x ?? fatalError()` 
>> since that is naturally what will be possible once the `Never` type is a 
>> real bottom type. If you want to use `!!` for the `x !! “bad things!”` 
>> convenience form, I don’t care. But the `Never` form should definitely, 
>> definitely use `??`.
>> 
>>> On Jun 28, 2017, at 1:30 PM, Erica Sadun via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Based on the feedback on this thread, I'm coming to the following 
>>> conclusions:
>>> 
>>> `!!` sends the right semantic message. "Unwrap or die" is an unsafe 
>>> operation. It is based on `!`, the unsafe forced unwrap operator, and not 
>>> on `??`, the safe fallback nil-coalescing operator. Its symbology should 
>>> therefore follow `!` and not `?`. 
>>> 
>>> The `!!` operator should follow the same semantics as 
>>> `Optional.unsafelyUnwrapped`, which establishes a precedent for this 
>>> approach:
>>> 
>>> > "The unsafelyUnwrapped property provides the same value as the forced 
>>> > unwrap operator (postfix !). However, in optimized builds (-O), no check 
>>> > is performed to ensure that the current instance actually has a value. 
>>> > Accessing this property in the case of a nil value is a serious 
>>> > programming error and could lead to undefined behavior or a runtime 
>>> > error."
>>> 
>>> By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
>>> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
>>>  
>>> 
>>> 
>>> > "Logic failures are intended to be handled by fixing the code. It means 
>>> > checks of logic failures can be removed if the code is tested enough.
>>> Actually checks of logic failures for various operations, `!`, `array[i]`, 
>>> `&+` and so on, are designed and implemented to be removed
>>> when we use `-Ounchecked`. It is useful for heavy computation like image 
>>> processing and machine learning in which overhead of those checks is not 
>>> permissible."
>>> 
>>> The right hand side should use a string (or more properly a string 
>>> autoclosure) in preference to using a `Never` bottom type or a `() -> 
>>> Never` closure. A string provides the cleanest user experience, and allows 
>>> the greatest degree of self-documentation. 
>>> 
>>> - A string is cleaner and more readable to type. It respects DRY, and 
>>> avoids using *both* the operator and the call to `fatalError` or 
>>> `preconditionFailure` to signal an unsafe condition:
>>> `let last = array.last !! “Array guaranteed non-empty" // readable`
>>> than: 
>>> `let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
>>> redundant, violates DRY`
>>> 
>>> - A string allows the operator *itself* to unsafely fail, just as the unary 
>>> version of `!` does now. It does this with additional feedback to the 
>>> developer during testing, code reading, and code maintenance. The string 
>>> provides a self-auditing in-line annotation of the reason why the forced 
>>> unwrap has been well considered, using a language construct to support this.
>>> 
>>> - A string disallows a potentially unsafe `Never` call that does not 
>>> reflect a serious programming error, for example:
>>> let last = array.last !! f() // where func f() -> Never { while true {} }
>>> 
>>> - Although as several list members mention, a `Never` closure solution is 
>>> available today in Swift, so is the `!!` operator solution. Neither one 
>>> requires a fundamental change to the language.
>>> 
>>> - Pushing forward on this proposal does not in any way reflect on adopting 
>>> the still-desirable `Never` bottom type.
>>> 
 On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 
 On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong >>> > wrote:
> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Well the main debate is that, we all want early access to a feature that 
> will be part of Swift as soon as `Never` become

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

Yeah, well I’m not a fan of the ‘syntactically convenience features only’ like 
`!!` as well, but I wouldn’t mind having the `??` overload now.

-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2017 um 23:57:59, Jaden Geller (jaden.gel...@gmail.com) schrieb:

I realize that, which is why I’m strongly against this proposal. I could 
potentially be for adding the `??` overload temporarily, but I don’t really 
feel it is necessary either.

On Jun 28, 2017, at 2:55 PM, Adrian Zubarev  
wrote:

Besides all that Never as a bottom type means that you can use fatalError() 
literally everywhere not only on the RHS of ??.

func foo(_: Int) {}

foo(fatalError())
That said, we can kill our application everywhere we would ever imagine, 
regardless of whether there is ? or ! operator present somewhere.




-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2017 um 23:50:18, Jaden Geller via swift-evolution 
(swift-evolution@swift.org) schrieb:

I’m strongly against not using the `??` operator for `x ?? fatalError()` since 
that is naturally what will be possible once the `Never` type is a real bottom 
type. If you want to use `!!` for the `x !! “bad things!”` convenience form, I 
don’t care. But the `Never` form should definitely, definitely use `??`.

On Jun 28, 2017, at 1:30 PM, Erica Sadun via swift-evolution 
 wrote:

Based on the feedback on this thread, I'm coming to the following conclusions:

`!!` sends the right semantic message. "Unwrap or die" is an unsafe operation. 
It is based on `!`, the unsafe forced unwrap operator, and not on `??`, the 
safe fallback nil-coalescing operator. Its symbology should therefore follow 
`!` and not `?`. 

The `!!` operator should follow the same semantics as 
`Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:

> "The unsafelyUnwrapped property provides the same value as the forced unwrap 
> operator (postfix !). However, in optimized builds (-O), no check is 
> performed to ensure that the current instance actually has a value. Accessing 
> this property in the case of a nil value is a serious programming error and 
> could lead to undefined behavior or a runtime error."

By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures

> "Logic failures are intended to be handled by fixing the code. It means 
> checks of logic failures can be removed if the code is tested enough.
Actually checks of logic failures for various operations, `!`, `array[i]`, `&+` 
and so on, are designed and implemented to be removed
when we use `-Ounchecked`. It is useful for heavy computation like image 
processing and machine learning in which overhead of those checks is not 
permissible."

The right hand side should use a string (or more properly a string autoclosure) 
in preference to using a `Never` bottom type or a `() -> Never` closure. A 
string provides the cleanest user experience, and allows the greatest degree of 
self-documentation. 

- A string is cleaner and more readable to type. It respects DRY, and avoids 
using *both* the operator and the call to `fatalError` or `preconditionFailure` 
to signal an unsafe condition:
`let last = array.last !! “Array guaranteed non-empty" // readable`
than: 
`let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
redundant, violates DRY`

- A string allows the operator *itself* to unsafely fail, just as the unary 
version of `!` does now. It does this with additional feedback to the developer 
during testing, code reading, and code maintenance. The string provides a 
self-auditing in-line annotation of the reason why the forced unwrap has been 
well considered, using a language construct to support this.

- A string disallows a potentially unsafe `Never` call that does not reflect a 
serious programming error, for example:
let last = array.last !! f() // where func f() -> Never { while true {} }

- Although as several list members mention, a `Never` closure solution is 
available today in Swift, so is the `!!` operator solution. Neither one 
requires a fundamental change to the language.

- Pushing forward on this proposal does not in any way reflect on adopting the 
still-desirable `Never` bottom type.

On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
 wrote:



On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
 wrote:

Well the main debate is that, we all want early access to a feature that will 
be part of Swift as soon as `Never` becomes the bottom type. When this happens 
the `??` will automatically support the pitched behavior. Until then if we all 
agree that we should add it now in a way that will not break anything we can 
simply add an overload to `??` as I previously showed.


I believe we should add it now, but I like the recent observation that making 
?? suddenly become a potentially crashing operator viola

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

> On Jun 28, 2017, at 3:46 PM, Jordan Rose  wrote:
> 
> 
> 
>> On Jun 28, 2017, at 14:40, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> The `!!` operator should follow the same semantics as 
>> `Optional.unsafelyUnwrapped`, which establishes a precedent for this 
>> approach:
>> 
>> > "The unsafelyUnwrapped property provides the same value as the forced 
>> > unwrap operator (postfix !). However, in optimized builds (-O), no check 
>> > is performed to ensure that the current instance actually has a value. 
>> > Accessing this property in the case of a nil value is a serious 
>> > programming error and could lead to undefined behavior or a runtime error."
> 
> Note that 'unsafelyUnwrapped' does not perform the check in optimized builds 
> (like 'assert'), while '!' does (like 'precondition'). If we go with '!!', it 
> should behave like 'precondition', not 'assert'.
> 
> Jordan

Noted and will incorporate into updated text

Thanks, -- E

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

Besides all that Never as a bottom type means that you can use fatalError() 
literally everywhere not only on the RHS of ??.

func foo(_: Int) {}

foo(fatalError())
That said, we can kill our application everywhere we would ever imagine, 
regardless of whether there is ? or ! operator present somewhere.



-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2017 um 23:50:18, Jaden Geller via swift-evolution 
(swift-evolution@swift.org) schrieb:

I’m strongly against not using the `??` operator for `x ?? fatalError()` since 
that is naturally what will be possible once the `Never` type is a real bottom 
type. If you want to use `!!` for the `x !! “bad things!”` convenience form, I 
don’t care. But the `Never` form should definitely, definitely use `??`.

On Jun 28, 2017, at 1:30 PM, Erica Sadun via swift-evolution 
 wrote:

Based on the feedback on this thread, I'm coming to the following conclusions:

`!!` sends the right semantic message. "Unwrap or die" is an unsafe operation. 
It is based on `!`, the unsafe forced unwrap operator, and not on `??`, the 
safe fallback nil-coalescing operator. Its symbology should therefore follow 
`!` and not `?`. 

The `!!` operator should follow the same semantics as 
`Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:

> "The unsafelyUnwrapped property provides the same value as the forced unwrap 
> operator (postfix !). However, in optimized builds (-O), no check is 
> performed to ensure that the current instance actually has a value. Accessing 
> this property in the case of a nil value is a serious programming error and 
> could lead to undefined behavior or a runtime error."

By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures

> "Logic failures are intended to be handled by fixing the code. It means 
> checks of logic failures can be removed if the code is tested enough.
Actually checks of logic failures for various operations, `!`, `array[i]`, `&+` 
and so on, are designed and implemented to be removed
when we use `-Ounchecked`. It is useful for heavy computation like image 
processing and machine learning in which overhead of those checks is not 
permissible."

The right hand side should use a string (or more properly a string autoclosure) 
in preference to using a `Never` bottom type or a `() -> Never` closure. A 
string provides the cleanest user experience, and allows the greatest degree of 
self-documentation. 

- A string is cleaner and more readable to type. It respects DRY, and avoids 
using *both* the operator and the call to `fatalError` or `preconditionFailure` 
to signal an unsafe condition:
`let last = array.last !! “Array guaranteed non-empty" // readable`
than: 
`let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
redundant, violates DRY`

- A string allows the operator *itself* to unsafely fail, just as the unary 
version of `!` does now. It does this with additional feedback to the developer 
during testing, code reading, and code maintenance. The string provides a 
self-auditing in-line annotation of the reason why the forced unwrap has been 
well considered, using a language construct to support this.

- A string disallows a potentially unsafe `Never` call that does not reflect a 
serious programming error, for example:
let last = array.last !! f() // where func f() -> Never { while true {} }

- Although as several list members mention, a `Never` closure solution is 
available today in Swift, so is the `!!` operator solution. Neither one 
requires a fundamental change to the language.

- Pushing forward on this proposal does not in any way reflect on adopting the 
still-desirable `Never` bottom type.

On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
 wrote:



On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
 wrote:

Well the main debate is that, we all want early access to a feature that will 
be part of Swift as soon as `Never` becomes the bottom type. When this happens 
the `??` will automatically support the pitched behavior. Until then if we all 
agree that we should add it now in a way that will not break anything we can 
simply add an overload to `??` as I previously showed.


I believe we should add it now, but I like the recent observation that making 
?? suddenly become a potentially crashing operator violates the expectation 
that ? is an indication of safety.

?? does *not* become a potentially crashing operator. The *fatalError* (or 
whatever else the user chooses to put there) on the right-hand side is the 
crashing operation.


On the other hand, the existing semantics of Swift are that ! is always 
dangerous, so making !! be the a potentially crashing operator is much more 
consistent with the language.

There is no need for `!!` because it will fade in the future. If you think of 
`Never

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[ilya via swift-evolution]

I'm unconvinced. We already have the perfectly functional "unwrap or die"
operator, that is, the *force unwrap* *! *operator.

Can it be improved? Definitely. If the developer wants to provide some
context for a possible fatal error, it would be great for the language to
give the tools to express it.

Perhaps we can examine a more general problem of improving debugging output
for symbols and operations. We can already associate some information with
functions and classes using the documentation markup. Why not build on that?

One could, for example, extend the existing* documentation markup sign*
*///* to pick up text as force unwrap messages:

`let last = array.last! /// Array guaranteed non-empty`

Best,
Ilya.

On Wed, Jun 28, 2017 at 11:00 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Based on the feedback on this thread, I'm coming to the following
> conclusions:
>
> `!!` sends the *right semantic message*. "Unwrap or die" is an unsafe
> operation. It is based on `!`, the unsafe forced unwrap operator, and not
> on `??`, the safe fallback nil-coalescing operator. Its symbology should
> therefore follow `!` and not `?`.
>
> The `!!` operator should follow the same semantics as `
> Optional.unsafelyUnwrapped`, which establishes a precedent for this
> approach:
>
> > "*The unsafelyUnwrapped property provides the same value as the forced
> unwrap operator (postfix !). However, in optimized builds (-O), no check is
> performed to ensure that the current instance actually has a value.
> Accessing this property in the case of a nil value is a serious programming
> error and could lead to undefined behavior or a runtime error.*"
>
>
> By following `Optional.unsafelyUnwrapped`, this approach is consistent
> with
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
>
>
>
> *> "Logic failures are intended to be handled by fixing the code. It
> means checks of logic failures can be removed if the code is tested
> enough.Actually checks of logic failures for various operations,
> `!`, `array[i]`, `&+` and so on, are designed and implemented to be
> removedwhen we use `-Ounchecked`. It is useful for heavy computation
> like image processing and machine learning in which overhead of
> those checks is not permissible."*
>
>
> The right hand side should use a string (or more properly a string
> autoclosure) in preference to using a `Never` bottom type or a `() ->
> Never` closure. A string provides the cleanest user experience, and
> allows the greatest degree of self-documentation.
>
> - A string is cleaner and more readable to type. It respects DRY, and
> avoids using *both* the operator and the call to `fatalError` or
> `preconditionFailure` to signal an unsafe condition:
>
> `let last = array.last !! “Array guaranteed non-empty" // readable`
>
> than:
>
> `let last = array.last !! fatalError(“Array guaranteed non-empty”) //
> redundant, violates DRY`
>
> - A string allows the operator **itself** to unsafely fail, just as the
> unary version of `!` does now. It does this with additional feedback to the
> developer during testing, code reading, and code maintenance. The string
> provides a self-auditing in-line annotation of the reason why the forced
> unwrap has been well considered, using a language construct to support this.
>
> - A string disallows a potentially unsafe `Never` call that does not
> reflect a serious programming error, for example:
>
> let last = array.last !! f() // where func f() -> Never { while true {} }
>
>
> - Although as several list members mention, a `Never` closure solution is
> available today in Swift, so is the `!!` operator solution. Neither one
> requires a fundamental change to the language.
>
> - Pushing forward on this proposal does not in any way reflect on adopting
> the still-desirable `Never` bottom type.
>
> On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  wrote:
>
>> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Well the main debate is that, we all want early access to a feature that
>> will be part of Swift as soon as `Never` becomes the bottom type. When this
>> happens the `??` will automatically support the pitched behavior. Until
>> then if we all agree that we should add it now in a way that will not break
>> anything we can simply add an overload to `??` as I previously showed.
>>
>>
>> I believe we should add it now, but I like the recent observation that
>> making ?? suddenly become a potentially crashing operator violates the
>> expectation that ? is an indication of safety.
>>
>
> ?? does *not* become a potentially crashing operator. The *fatalError* (or
> whatever else the user chooses to put there) on the right-hand side is the
> crashing operation.
>
>
>> On the other hand, the existing semantics of Swift are that ! is alwa

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jordan Rose via swift-evolution]

> On Jun 28, 2017, at 14:40, Erica Sadun via swift-evolution 
>  wrote:
> 
> The `!!` operator should follow the same semantics as 
> `Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:
> 
> > "The unsafelyUnwrapped property provides the same value as the forced 
> > unwrap operator (postfix !). However, in optimized builds (-O), no check is 
> > performed to ensure that the current instance actually has a value. 
> > Accessing this property in the case of a nil value is a serious programming 
> > error and could lead to undefined behavior or a runtime error."

Note that 'unsafelyUnwrapped' does not perform the check in optimized builds 
(like 'assert'), while '!' does (like 'precondition'). If we go with '!!', it 
should behave like 'precondition', not 'assert'.

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

Exactly, that’s what I was aiming for by the `@autoclosure () -> Never`.

PS: I want to apologize for tons of typos I made in my last post. Just realized 
it now :/

-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2017 um 20:42:38, Tony Allevato (tony.allev...@gmail.com) schrieb:



On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
 wrote:

Well the main debate is that, we all want early access to a feature that will 
be part of Swift as soon as `Never` becomes the bottom type. When this happens 
the `??` will automatically support the pitched behavior. Until then if we all 
agree that we should add it now in a way that will not break anything we can 
simply add an overload to `??` as I previously showed.


I believe we should add it now, but I like the recent observation that making 
?? suddenly become a potentially crashing operator violates the expectation 
that ? is an indication of safety.

?? does *not* become a potentially crashing operator. The *fatalError* (or 
whatever else the user chooses to put there) on the right-hand side is the 
crashing operation.


On the other hand, the existing semantics of Swift are that ! is always 
dangerous, so making !! be the a potentially crashing operator is much more 
consistent with the language.

There is no need for `!!` because it will fade in the future. If you think of 
`Never` as a bottom type now then `??` will already make total sense. The 
default value for T from rhs might be T or Never. 

I respectfully disagree with your absolute position on this topic. Even with 
Never as a bottom type in the future, it would still be more convenient for me 
to type:

let last = array.last !! “Array must be non-empty"

… than it ever would be to type:

let last = array.last ?? fatalError(“Array must be non-empty”)


There is a very high bar for additions to the standard library—a new operator 
added to the language is going to be around (1) forever, or (2) indefinitely 
with some migration cost to users if it's ever removed. Shaving off a few 
keystrokes doesn't quite meet that bar—especially when an alternative has been 
shown to work already that provides the same functionality, is more general 
(not coupled to fatalError or String messages), and that fits better into 
Swift's design.


To make sure I'm not being too much of a downer, I would completely support 
this broader feature being implemented by that alternative: the ?? + 
autoclosure () -> Never combo. Then once Never does become a true bottom type, 
I believe it could be removed and the calling code would still *just work*.

 
Dave


@erica: the rhs argument should be called something like `noreturnOrError` and 
not `defaultValue`. And we should keep in mind that when Never becomes the 
bottom type we have to remove that overload from stdlib, because otherwise it 
will be ambiguous. 

---

On the other hand if we tackle a different operator then we should rething the 
'default value operator' because the second ? signals an optional but not a 
non-optional or an inplicit unwrapped operator. In that case I personally thing 
?! would make more sense. Unwrap or (non-optional | IUO | trap/die)

-- 
Adrian Zubarev
Sent with Airmail
Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution 
(swift-evolution@swift.org) schrieb:

It's hard for me to articulate, but "foo !! message" feels a little too much 
like a Perl-ism for my taste. Objectively that's not a great criticism on its 
own, but I just don't like the "smell" of an operator that takes a value on one 
side and a string for error reporting purposes on the other. It doesn't feel 
like it fits the style of Swift. I prefer a version that makes the call to 
fatalError (and thus, any other non-returning handler) explicitly written out 
in code.

So, if the language can already support this with ?? and autoclosure/Never as 
was shown above, I'd rather see that added to the language instead of a new 
operator that does the same thing (and is actually less general).

On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution 
 wrote:
I feel that the !! operator would be necessary for indicating that if this 
fails then something went horribly wrong somewhere and we should throw the 
fatalError. This allows the inclusion of optimizations using -Ounchecked and is 
clear that this is an operation that could result in a runtime error just like 
force unwrapping.

If we want code clarity and uniformity, then I think !! Is much better than ?? 
because it goes right along with the single ! Used for force unwrapping. 
However, this does depend on if the operator would be returning some kind of 
error that would cause the program to exit.

I think the ?? operator should not cause a program to exit early. It goes 
against optional unwrapping principles. I think code could get very confusing 
if some ? would return nil/a default value, and others would be causing your 
program to cras

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jaden Geller via swift-evolution]

> On Jun 28, 2017, at 7:47 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 3:52 AM, Yuta Koshizawa via swift-evolution 
>>  wrote:
>> 
>> Hi, I think it is an orthogonal issue if we need a new operator. It is
>> also possible to introduce an infix `!` for it.
>> 
>> I am sure that we do not need to avoid `precondition` as long as we
>> use it appropriately. It is useful to realize consistent behavior with
>> `Array`'s `subscript`, forced unwrapping `!`, `&+` and so on. In this
>> context, `precondition` does not mean a general word "precondition"
>> but the `precondition` function in the Swift standard library, which
>> is removed when -Ounchecked.
> 
> 
> How would the line run then? Would it simply act as a forced unwrapped under 
> -Ounchecked? 

From the docs:

"In -Ounchecked builds, the optimizer may assume that this function is never 
called. Failure to satisfy that assumption is a serious programming error.”

Aka, v. bad things happen if the precondition does not hold.

> 
> -- E
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Jaden Geller via swift-evolution]

I’m strongly against not using the `??` operator for `x ?? fatalError()` since 
that is naturally what will be possible once the `Never` type is a real bottom 
type. If you want to use `!!` for the `x !! “bad things!”` convenience form, I 
don’t care. But the `Never` form should definitely, definitely use `??`.

> On Jun 28, 2017, at 1:30 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Based on the feedback on this thread, I'm coming to the following conclusions:
> 
> `!!` sends the right semantic message. "Unwrap or die" is an unsafe 
> operation. It is based on `!`, the unsafe forced unwrap operator, and not on 
> `??`, the safe fallback nil-coalescing operator. Its symbology should 
> therefore follow `!` and not `?`. 
> 
> The `!!` operator should follow the same semantics as 
> `Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:
> 
> > "The unsafelyUnwrapped property provides the same value as the forced 
> > unwrap operator (postfix !). However, in optimized builds (-O), no check is 
> > performed to ensure that the current instance actually has a value. 
> > Accessing this property in the case of a nil value is a serious programming 
> > error and could lead to undefined behavior or a runtime error."
> 
> By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
>  
> 
> 
> > "Logic failures are intended to be handled by fixing the code. It means 
> > checks of logic failures can be removed if the code is tested enough.
> Actually checks of logic failures for various operations, `!`, `array[i]`, 
> `&+` and so on, are designed and implemented to be removed
> when we use `-Ounchecked`. It is useful for heavy computation like image 
> processing and machine learning in which overhead of those checks is not 
> permissible."
> 
> The right hand side should use a string (or more properly a string 
> autoclosure) in preference to using a `Never` bottom type or a `() -> Never` 
> closure. A string provides the cleanest user experience, and allows the 
> greatest degree of self-documentation. 
> 
> - A string is cleaner and more readable to type. It respects DRY, and avoids 
> using *both* the operator and the call to `fatalError` or 
> `preconditionFailure` to signal an unsafe condition:
> `let last = array.last !! “Array guaranteed non-empty" // readable`
> than: 
> `let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
> redundant, violates DRY`
> 
> - A string allows the operator *itself* to unsafely fail, just as the unary 
> version of `!` does now. It does this with additional feedback to the 
> developer during testing, code reading, and code maintenance. The string 
> provides a self-auditing in-line annotation of the reason why the forced 
> unwrap has been well considered, using a language construct to support this.
> 
> - A string disallows a potentially unsafe `Never` call that does not reflect 
> a serious programming error, for example:
> let last = array.last !! f() // where func f() -> Never { while true {} }
> 
> - Although as several list members mention, a `Never` closure solution is 
> available today in Swift, so is the `!!` operator solution. Neither one 
> requires a fundamental change to the language.
> 
> - Pushing forward on this proposal does not in any way reflect on adopting 
> the still-desirable `Never` bottom type.
> 
>> On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong > > wrote:
>>> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Well the main debate is that, we all want early access to a feature that 
>>> will be part of Swift as soon as `Never` becomes the bottom type. When this 
>>> happens the `??` will automatically support the pitched behavior. Until 
>>> then if we all agree that we should add it now in a way that will not break 
>>> anything we can simply add an overload to `??` as I previously showed.
>>> 
>> 
>> I believe we should add it now, but I like the recent observation that 
>> making ?? suddenly become a potentially crashing operator violates the 
>> expectation that ? is an indication of safety.
>> 
>> ?? does *not* become a potentially crashing operator. The *fatalError* (or 
>> whatever else the user chooses to put there) on the right-hand side is the 
>> crashing operation.
>> 
>> 
>> On the other hand, the existing semantics of Swift are that ! is always 
>> dangerous, so making !! be the a potentially crashing operator is much more 
>> consistent with the language.
>> 
>>> There is no need for `!!` because it will fade in the future. If you think 
>>> of `Never` as a bottom type now then `?

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

Okay, I’m starting to get on board with !!, but (remaining follows inline):

> On 28 Jun 2017, at 22:30, Erica Sadun via swift-evolution 
>  wrote:
> 
> Based on the feedback on this thread, I'm coming to the following conclusions:
> 
> `!!` sends the right semantic message. "Unwrap or die" is an unsafe 
> operation. It is based on `!`, the unsafe forced unwrap operator, and not on 
> `??`, the safe fallback nil-coalescing operator. Its symbology should 
> therefore follow `!` and not `?`. 
> 
> The `!!` operator should follow the same semantics as 
> `Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:
> 
> > "The unsafelyUnwrapped property provides the same value as the forced 
> > unwrap operator (postfix !). However, in optimized builds (-O), no check is 
> > performed to ensure that the current instance actually has a value. 
> > Accessing this property in the case of a nil value is a serious programming 
> > error and could lead to undefined behavior or a runtime error."
> 
> By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
>  
> 
> 
> > "Logic failures are intended to be handled by fixing the code. It means 
> > checks of logic failures can be removed if the code is tested enough.
> Actually checks of logic failures for various operations, `!`, `array[i]`, 
> `&+` and so on, are designed and implemented to be removed
> when we use `-Ounchecked`. It is useful for heavy computation like image 
> processing and machine learning in which overhead of those checks is not 
> permissible."
> 
> The right hand side should use a string (or more properly a string 
> autoclosure) in preference to using a `Never` bottom type or a `() -> Never` 
> closure. A string provides the cleanest user experience, and allows the 
> greatest degree of self-documentation. 
> 
> - A string is cleaner and more readable to type. It respects DRY, and avoids 
> using *both* the operator and the call to `fatalError` or 
> `preconditionFailure` to signal an unsafe condition:
> `let last = array.last !! “Array guaranteed non-empty" // readable`
> than: 
> `let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
> redundant, violates DRY`

I’d still like a () -> Never override to provide customisation:

let last = array.last !! logAndTrap(“Array guaranteed non-empty”)

> - A string allows the operator *itself* to unsafely fail, just as the unary 
> version of `!` does now. It does this with additional feedback to the 
> developer during testing, code reading, and code maintenance. The string 
> provides a self-auditing in-line annotation of the reason why the forced 
> unwrap has been well considered, using a language construct to support this.
> 
> - A string disallows a potentially unsafe `Never` call that does not reflect 
> a serious programming error, for example:
> let last = array.last !! f() // where func f() -> Never { while true {} }
> 
> - Although as several list members mention, a `Never` closure solution is 
> available today in Swift, so is the `!!` operator solution. Neither one 
> requires a fundamental change to the language.
> 
> - Pushing forward on this proposal does not in any way reflect on adopting 
> the still-desirable `Never` bottom type.
> 
>> On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong > > wrote:
>>> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Well the main debate is that, we all want early access to a feature that 
>>> will be part of Swift as soon as `Never` becomes the bottom type. When this 
>>> happens the `??` will automatically support the pitched behavior. Until 
>>> then if we all agree that we should add it now in a way that will not break 
>>> anything we can simply add an overload to `??` as I previously showed.
>>> 
>> 
>> I believe we should add it now, but I like the recent observation that 
>> making ?? suddenly become a potentially crashing operator violates the 
>> expectation that ? is an indication of safety.
>> 
>> ?? does *not* become a potentially crashing operator. The *fatalError* (or 
>> whatever else the user chooses to put there) on the right-hand side is the 
>> crashing operation.
>> 
>> 
>> On the other hand, the existing semantics of Swift are that ! is always 
>> dangerous, so making !! be the a potentially crashing operator is much more 
>> consistent with the language.
>> 
>>> There is no need for `!!` because it will fade in the future. If you think 
>>> of `Never` as a bottom type now then `??` will already make total sense. 
>>> The default value for T from rhs might be T or Never. 
>> 
>> I respect

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 28 Jun 2017, at 17:35, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 6:03 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
>> argue both ways, with the goal in reading code as "unwrap or die".
>> 
> 
> 
> Personally, I strongly prefer `foo !! "explanation"` over `foo ?? 
> fatalError()`. I don’t think adding another operator for what is a very 
> common need is a concern, and is easier to read at a glance than the 
> ??/fatalError combo.  There is a bit of cognitive dissonance

Actually, the cognitive dissonance argument is a strong one. Its true that ?? 
doesn’t evoke trapping.

> between ??, a normally-fluffy nonthreatening defaulting operator, and 
> fatalError, a scary beware operator. `!!` OTOH matches `!` in clearly 
> flagging the unwrap as unsafe and that your program will exit. I also think 
> it would be easier to explain `!!` to beginners as part of a wider story 
> explaining optionals in general, unwraps, what `nil` means and what `!` means 
> etc. Whereas `foo ?? Never` requires a lot of heavy lifting to understand 
> how/why it works – we might all understand it, but that understanding is 
> built on a lot of foundational understanding.
> 
> I also think a `Never` type would be very useful. Just that for this 
> particular case, `!!` is still worth adding too.
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 28 Jun 2017, at 17:41, Ben Cohen  wrote:
> 
> 
>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Count me in as a strong proponent of ?? () -> Never. We don't need to burden 
>> the language with an extra operator just for that.
> 
> You could say the same about ??

I have more difficulties saying the same for ?? as it provides a lot of value: 
a RHS Optional override and potentially a RHS Never closure override which 
would allow us to customise what happens before trapping. On the other hand, 
the !! operator, while useful, only provides a trapping behaviour with no way 
tu customise it.

> The concern that an additional operator (and one that, IMO, fits well into 
> existing patterns) is so burdensome seems way overweighted in this discussion 
> IMO. 
> 
> Adding the operator, and encouraging its use, will help foster better 
> understanding of optionals and legitimate use of force-unwrapping in a way 
> that I don’t think `?? fatalError` could.

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

Based on the feedback on this thread, I'm coming to the following conclusions:

`!!` sends the right semantic message. "Unwrap or die" is an unsafe operation. 
It is based on `!`, the unsafe forced unwrap operator, and not on `??`, the 
safe fallback nil-coalescing operator. Its symbology should therefore follow 
`!` and not `?`. 

The `!!` operator should follow the same semantics as 
`Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:

> "The unsafelyUnwrapped property provides the same value as the forced unwrap 
> operator (postfix !). However, in optimized builds (-O), no check is 
> performed to ensure that the current instance actually has a value. Accessing 
> this property in the case of a nil value is a serious programming error and 
> could lead to undefined behavior or a runtime error."

By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
 


> "Logic failures are intended to be handled by fixing the code. It means 
> checks of logic failures can be removed if the code is tested enough.
Actually checks of logic failures for various operations, `!`, `array[i]`, `&+` 
and so on, are designed and implemented to be removed
when we use `-Ounchecked`. It is useful for heavy computation like image 
processing and machine learning in which overhead of those checks is not 
permissible."

The right hand side should use a string (or more properly a string autoclosure) 
in preference to using a `Never` bottom type or a `() -> Never` closure. A 
string provides the cleanest user experience, and allows the greatest degree of 
self-documentation. 

- A string is cleaner and more readable to type. It respects DRY, and avoids 
using *both* the operator and the call to `fatalError` or `preconditionFailure` 
to signal an unsafe condition:
`let last = array.last !! “Array guaranteed non-empty" // readable`
than: 
`let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
redundant, violates DRY`

- A string allows the operator *itself* to unsafely fail, just as the unary 
version of `!` does now. It does this with additional feedback to the developer 
during testing, code reading, and code maintenance. The string provides a 
self-auditing in-line annotation of the reason why the forced unwrap has been 
well considered, using a language construct to support this.

- A string disallows a potentially unsafe `Never` call that does not reflect a 
serious programming error, for example:
let last = array.last !! f() // where func f() -> Never { while true {} }

- Although as several list members mention, a `Never` closure solution is 
available today in Swift, so is the `!!` operator solution. Neither one 
requires a fundamental change to the language.

- Pushing forward on this proposal does not in any way reflect on adopting the 
still-desirable `Never` bottom type.

> On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  > wrote:
>> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Well the main debate is that, we all want early access to a feature that 
>> will be part of Swift as soon as `Never` becomes the bottom type. When this 
>> happens the `??` will automatically support the pitched behavior. Until then 
>> if we all agree that we should add it now in a way that will not break 
>> anything we can simply add an overload to `??` as I previously showed.
>> 
> 
> I believe we should add it now, but I like the recent observation that making 
> ?? suddenly become a potentially crashing operator violates the expectation 
> that ? is an indication of safety.
> 
> ?? does *not* become a potentially crashing operator. The *fatalError* (or 
> whatever else the user chooses to put there) on the right-hand side is the 
> crashing operation.
> 
> 
> On the other hand, the existing semantics of Swift are that ! is always 
> dangerous, so making !! be the a potentially crashing operator is much more 
> consistent with the language.
> 
>> There is no need for `!!` because it will fade in the future. If you think 
>> of `Never` as a bottom type now then `??` will already make total sense. The 
>> default value for T from rhs might be T or Never. 
> 
> I respectfully disagree with your absolute position on this topic. Even with 
> Never as a bottom type in the future, it would still be more convenient for 
> me to type:
> 
> let last = array.last !! “Array must be non-empty"
> 
> … than it ever would be to type:
> 
> let last = array.last ?? fatalError(“Array must be non-empty”)
> 
> 
> There is a very high bar for additions to the standard library—a new operator 
> added to the language is going to be around (1) forever

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Tony Allevato via swift-evolution]

On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  wrote:

> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Well the main debate is that, we all want early access to a feature that
> will be part of Swift as soon as `Never` becomes the bottom type. When this
> happens the `??` will automatically support the pitched behavior. Until
> then if we all agree that we should add it now in a way that will not break
> anything we can simply add an overload to `??` as I previously showed.
>
>
> I believe we should add it now, but I like the recent observation that
> making ?? suddenly become a potentially crashing operator violates the
> expectation that ? is an indication of safety.
>

?? does *not* become a potentially crashing operator. The *fatalError* (or
whatever else the user chooses to put there) on the right-hand side is the
crashing operation.


> On the other hand, the existing semantics of Swift are that ! is always
> dangerous, so making !! be the a potentially crashing operator is much
> more consistent with the language.
>
> There is no need for `!!` because it will fade in the future. If you think
> of `Never` as a bottom type now then `??` will already make total sense.
> The default value for T from rhs might be T or Never.
>
>
> I respectfully disagree with your absolute position on this topic. Even
> with Never as a bottom type in the future, it would *still* be more
> convenient for me to type:
>
> let last = array.last !! “Array must be non-empty"
>
> … than it ever would be to type:
>
> let last = array.last ?? fatalError(“Array must be non-empty”)
>
>
There is a very high bar for additions to the standard library—a new
operator added to the language is going to be around (1) forever, or (2)
indefinitely with some migration cost to users if it's ever removed.
Shaving off a few keystrokes doesn't quite meet that bar—especially when an
alternative has been shown to work already that provides the same
functionality, is more general (not coupled to fatalError or String
messages), and that fits better into Swift's design.


To make sure I'm not being too much of a downer, I would completely support
this broader feature being implemented by that alternative: the ?? +
autoclosure () -> Never combo. Then once Never does become a true bottom
type, I believe it could be removed and the calling code would still *just
work*.



> Dave
>
>
> @erica: the rhs argument should be called something like `noreturnOrError`
> and not `defaultValue`. And we should keep in mind that when Never becomes
> the bottom type we have to remove that overload from stdlib, because
> otherwise it will be ambiguous.
>
> ---
>
> On the other hand if we tackle a different operator then we should rething
> the 'default value operator' because the second ? signals an optional but
> not a non-optional or an inplicit unwrapped operator. In that case I
> personally thing ?! would make more sense. Unwrap or (non-optional | IUO |
> trap/die)
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>> It's hard for me to articulate, but "foo !! message" feels a little too
>> much like a Perl-ism for my taste. Objectively that's not a great criticism
>> on its own, but I just don't like the "smell" of an operator that takes a
>> value on one side and a string for error reporting purposes on the other.
>> It doesn't feel like it fits the style of Swift. I prefer a version that
>> makes the call to fatalError (and thus, any other non-returning handler)
>> explicitly written out in code.
>>
>> So, if the language can already support this with ?? and
>> autoclosure/Never as was shown above, I'd rather see that added to the
>> language instead of a new operator that does the same thing (and is
>> actually less general).
>>
>> On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I feel that the !! operator would be necessary for indicating that if
>>> this fails then something went horribly wrong somewhere and we should throw
>>> the fatalError. This allows the inclusion of optimizations using
>>> -Ounchecked and is clear that this is an operation that could result in a
>>> runtime error just like force unwrapping.
>>>
>>> If we want code clarity and uniformity, then I think !! Is much better
>>> than ?? because it goes right along with the single ! Used for force
>>> unwrapping. However, this does depend on if the operator would be returning
>>> some kind of error that would cause the program to exit.
>>>
>>> I think the ?? operator should not cause a program to exit early. It
>>> goes against optional unwrapping principles. I think code could get very
>>> confusing if some ? would return nil/a default value, and others would be
>>> causing your program to crash and exit. The ? operators should always be
>>> classified as safe operation

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Well the main debate is that, we all want early access to a feature that will 
> be part of Swift as soon as `Never` becomes the bottom type. When this 
> happens the `??` will automatically support the pitched behavior. Until then 
> if we all agree that we should add it now in a way that will not break 
> anything we can simply add an overload to `??` as I previously showed.
> 

I believe we should add it now, but I like the recent observation that making 
?? suddenly become a potentially crashing operator violates the expectation 
that ? is an indication of safety.

On the other hand, the existing semantics of Swift are that ! is always 
dangerous, so making !! be the a potentially crashing operator is much more 
consistent with the language.

> There is no need for `!!` because it will fade in the future. If you think of 
> `Never` as a bottom type now then `??` will already make total sense. The 
> default value for T from rhs might be T or Never. 

I respectfully disagree with your absolute position on this topic. Even with 
Never as a bottom type in the future, it would still be more convenient for me 
to type:

let last = array.last !! “Array must be non-empty"

… than it ever would be to type:

let last = array.last ?? fatalError(“Array must be non-empty”)

Dave

> 
> @erica: the rhs argument should be called something like `noreturnOrError` 
> and not `defaultValue`. And we should keep in mind that when Never becomes 
> the bottom type we have to remove that overload from stdlib, because 
> otherwise it will be ambiguous. 
> 
> ---
> 
> On the other hand if we tackle a different operator then we should rething 
> the 'default value operator' because the second ? signals an optional but not 
> a non-optional or an inplicit unwrapped operator. In that case I personally 
> thing ?! would make more sense. Unwrap or (non-optional | IUO | trap/die)
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> It's hard for me to articulate, but "foo !! message" feels a little too much 
>> like a Perl-ism for my taste. Objectively that's not a great criticism on 
>> its own, but I just don't like the "smell" of an operator that takes a value 
>> on one side and a string for error reporting purposes on the other. It 
>> doesn't feel like it fits the style of Swift. I prefer a version that makes 
>> the call to fatalError (and thus, any other non-returning handler) 
>> explicitly written out in code.
>> 
>> So, if the language can already support this with ?? and autoclosure/Never 
>> as was shown above, I'd rather see that added to the language instead of a 
>> new operator that does the same thing (and is actually less general).
>> 
>> On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> I feel that the !! operator would be necessary for indicating that if this 
>> fails then something went horribly wrong somewhere and we should throw the 
>> fatalError. This allows the inclusion of optimizations using -Ounchecked and 
>> is clear that this is an operation that could result in a runtime error just 
>> like force unwrapping.
>> 
>> If we want code clarity and uniformity, then I think !! Is much better than 
>> ?? because it goes right along with the single ! Used for force unwrapping. 
>> However, this does depend on if the operator would be returning some kind of 
>> error that would cause the program to exit.
>> 
>> I think the ?? operator should not cause a program to exit early. It goes 
>> against optional unwrapping principles. I think code could get very 
>> confusing if some ? would return nil/a default value, and others would be 
>> causing your program to crash and exit. The ? operators should always be 
>> classified as safe operations.
>> 
>>> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Count me in as a strong proponent of ?? () -> Never. We don't need to 
 burden the language with an extra operator just for that.
>>> 
>>> You could say the same about ??
>>> 
>>> The concern that an additional operator (and one that, IMO, fits well into 
>>> existing patterns) is so burdensome seems way overweighted in this 
>>> discussion IMO. 
>>> 
>>> Adding the operator, and encouraging its use, will help foster better 
>>> understanding of optionals and legitimate use of force-unwrapping in a way 
>>> that I don’t think `?? fatalError` could.
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Max Moiseev via swift-evolution]

One argument against `?? () -> Never` is that `func f() -> Never { while true 
{} }` will also work.

Max

> On Jun 28, 2017, at 8:35 AM, Ben Cohen  wrote:
> 
> 
>> On Jun 28, 2017, at 6:03 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
>> argue both ways, with the goal in reading code as "unwrap or die".
>> 
> 
> 
> Personally, I strongly prefer `foo !! "explanation"` over `foo ?? 
> fatalError()`. I don’t think adding another operator for what is a very 
> common need is a concern, and is easier to read at a glance than the 
> ??/fatalError combo.  There is a bit of cognitive dissonance between ??, a 
> normally-fluffy nonthreatening defaulting operator, and fatalError, a scary 
> beware operator. `!!` OTOH matches `!` in clearly flagging the unwrap as 
> unsafe and that your program will exit. I also think it would be easier to 
> explain `!!` to beginners as part of a wider story explaining optionals in 
> general, unwraps, what `nil` means and what `!` means etc. Whereas `foo ?? 
> Never` requires a lot of heavy lifting to understand how/why it works – we 
> might all understand it, but that understanding is built on a lot of 
> foundational understanding.
> 
> I also think a `Never` type would be very useful. Just that for this 
> particular case, `!!` is still worth adding too.
> 
> 

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

Well the main debate is that, we all want early access to a feature that will 
be part of Swift as soon as `Never` becomes the bottom type. When this happens 
the `??` will automatically support the pitched behavior. Until then if we all 
agree that we should add it now in a way that will not break anything we can 
simply add an overload to `??` as I previously showed.  

There is no need for `!!` because it will fade in the future. If you think of 
`Never` as a bottom type now then `??` will already make total sense. The 
default value for T from rhs might be T or Never.  

@erica: the rhs argument should be called something like `noreturnOrError` and 
not `defaultValue`. And we should keep in mind that when Never becomes the 
bottom type we have to remove that overload from stdlib, because otherwise it 
will be ambiguous.  

---  

On the other hand if we tackle a different operator then we should rething the 
'default value operator' because the second ? signals an optional but not a 
non-optional or an inplicit unwrapped operator. In that case I personally thing 
?! would make more sense. Unwrap or (non-optional | IUO | trap/die)

--  
Adrian Zubarev
Sent with Airmail  

Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

>  
> It's hard for me to articulate, but "foo !! message" feels a little too much 
> like a Perl-ism for my taste. Objectively that's not a great criticism on its 
> own, but I just don't like the "smell" of an operator that takes a value on 
> one side and a string for error reporting purposes on the other. It doesn't 
> feel like it fits the style of Swift. I prefer a version that makes the call 
> to fatalError (and thus, any other non-returning handler) explicitly written 
> out in code.
>  
> So, if the language can already support this with ?? and autoclosure/Never as 
> was shown above, I'd rather see that added to the language instead of a new 
> operator that does the same thing (and is actually less general).  
>  
> On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution 
> mailto:swift-evolution@swift.org)> wrote:
> > I feel that the !! operator would be necessary for indicating that if this 
> > fails then something went horribly wrong somewhere and we should throw the 
> > fatalError. This allows the inclusion of optimizations using -Ounchecked 
> > and is clear that this is an operation that could result in a runtime error 
> > just like force unwrapping.  
> >  
> > If we want code clarity and uniformity, then I think !! Is much better than 
> > ?? because it goes right along with the single ! Used for force unwrapping. 
> > However, this does depend on if the operator would be returning some kind 
> > of error that would cause the program to exit.  
> >  
> > I think the ?? operator should not cause a program to exit early. It goes 
> > against optional unwrapping principles. I think code could get very 
> > confusing if some ? would return nil/a default value, and others would be 
> > causing your program to crash and exit. The ? operators should always be 
> > classified as safe operations.  
> >  
> > > On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution 
> > > mailto:swift-evolution@swift.org)> wrote:  
> > >  
> > > > On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
> > > > mailto:swift-evolution@swift.org)> wrote:  
> > > > Count me in as a strong proponent of ?? () -> Never. We don't need to 
> > > > burden the language with an extra operator just for that.
> > >  
> > > You could say the same about ??  
> > >  
> > > The concern that an additional operator (and one that, IMO, fits well 
> > > into existing patterns) is so burdensome seems way overweighted in this 
> > > discussion IMO.  
> > >  
> > > Adding the operator, and encouraging its use, will help foster better 
> > > understanding of optionals and legitimate use of force-unwrapping in a 
> > > way that I don’t think `?? fatalError` could.  
> > >  
> > >  
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >  
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto: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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

> On Jun 28, 2017, at 10:13 AM, Tony Allevato  wrote:
> 
> It's hard for me to articulate, but "foo !! message" feels a little too much 
> like a Perl-ism for my taste. Objectively that's not a great criticism on its 
> own, but I just don't like the "smell" of an operator that takes a value on 
> one side and a string for error reporting purposes on the other. It doesn't 
> feel like it fits the style of Swift. I prefer a version that makes the call 
> to fatalError (and thus, any other non-returning handler) explicitly written 
> out in code.
> 
> So, if the language can already support this with ?? and autoclosure/Never as 
> was shown above, I'd rather see that added to the language instead of a new 
> operator that does the same thing (and is actually less general).

I do see your point, and pardon my lack of familiarity with deeper swift 
capabilities, but would it be possible to restrict the !! operator to @noreturn 
closures rather than a string and just always throwing a fatalError? This would 
require the !! operator to have the error type explicitly spelt out, while 
still honoring the sentiment of !. It would feel more swifty, and you’d get the 
clarity of knowing that !! is an unsafe operation and you’d know exactly what 
kind of error is being thrown.

And then ?? could be left as-is and only used for default values.

> 
> On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I feel that the !! operator would be necessary for indicating that if this 
> fails then something went horribly wrong somewhere and we should throw the 
> fatalError. This allows the inclusion of optimizations using -Ounchecked and 
> is clear that this is an operation that could result in a runtime error just 
> like force unwrapping.
> 
> If we want code clarity and uniformity, then I think !! Is much better than 
> ?? because it goes right along with the single ! Used for force unwrapping. 
> However, this does depend on if the operator would be returning some kind of 
> error that would cause the program to exit.
> 
> I think the ?? operator should not cause a program to exit early. It goes 
> against optional unwrapping principles. I think code could get very confusing 
> if some ? would return nil/a default value, and others would be causing your 
> program to crash and exit. The ? operators should always be classified as 
> safe operations.
> 
>> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Count me in as a strong proponent of ?? () -> Never. We don't need to 
>>> burden the language with an extra operator just for that.
>> 
>> You could say the same about ??
>> 
>> The concern that an additional operator (and one that, IMO, fits well into 
>> existing patterns) is so burdensome seems way overweighted in this 
>> discussion IMO. 
>> 
>> Adding the operator, and encouraging its use, will help foster better 
>> understanding of optionals and legitimate use of force-unwrapping in a way 
>> that I don’t think `?? fatalError` could.
>> 
>> 
>> ___
>> 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] Introducing the "Unwrap or Die" operator to the standard library

[Tony Allevato via swift-evolution]

It's hard for me to articulate, but "foo !! message" feels a little too
much like a Perl-ism for my taste. Objectively that's not a great criticism
on its own, but I just don't like the "smell" of an operator that takes a
value on one side and a string for error reporting purposes on the other.
It doesn't feel like it fits the style of Swift. I prefer a version that
makes the call to fatalError (and thus, any other non-returning handler)
explicitly written out in code.

So, if the language can already support this with ?? and autoclosure/Never
as was shown above, I'd rather see that added to the language instead of a
new operator that does the same thing (and is actually less general).

On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution <
swift-evolution@swift.org> wrote:

> I feel that the !! operator would be necessary for indicating that if this
> fails then something went horribly wrong somewhere and we should throw the
> fatalError. This allows the inclusion of optimizations using -Ounchecked
> and is clear that this is an operation that could result in a runtime error
> just like force unwrapping.
>
> If we want code clarity and uniformity, then I think !! Is much better
> than ?? because it goes right along with the single ! Used for force
> unwrapping. However, this does depend on if the operator would be returning
> some kind of error that would cause the program to exit.
>
> I think the ?? operator should not cause a program to exit early. It goes
> against optional unwrapping principles. I think code could get very
> confusing if some ? would return nil/a default value, and others would be
> causing your program to crash and exit. The ? operators should always be
> classified as safe operations.
>
> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Count me in as a strong proponent of ?? () -> Never. We don't need to
> burden the language with an extra operator just for that.
>
>
> You could say the same about ??
>
> The concern that an additional operator (and one that, IMO, fits well into
> existing patterns) is so burdensome seems way overweighted in this
> discussion IMO.
>
> Adding the operator, and encouraging its use, will help foster better
> understanding of optionals and legitimate use of force-unwrapping in a way
> that I don’t think `?? fatalError` could.
>
>
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Williams via swift-evolution]

I feel that the !! operator would be necessary for indicating that if this 
fails then something went horribly wrong somewhere and we should throw the 
fatalError. This allows the inclusion of optimizations using -Ounchecked and is 
clear that this is an operation that could result in a runtime error just like 
force unwrapping.

If we want code clarity and uniformity, then I think !! Is much better than ?? 
because it goes right along with the single ! Used for force unwrapping. 
However, this does depend on if the operator would be returning some kind of 
error that would cause the program to exit.

I think the ?? operator should not cause a program to exit early. It goes 
against optional unwrapping principles. I think code could get very confusing 
if some ? would return nil/a default value, and others would be causing your 
program to crash and exit. The ? operators should always be classified as safe 
operations.

> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Count me in as a strong proponent of ?? () -> Never. We don't need to burden 
>> the language with an extra operator just for that.
> 
> You could say the same about ??
> 
> The concern that an additional operator (and one that, IMO, fits well into 
> existing patterns) is so burdensome seems way overweighted in this discussion 
> IMO. 
> 
> Adding the operator, and encouraging its use, will help foster better 
> understanding of optionals and legitimate use of force-unwrapping in a way 
> that I don’t think `?? fatalError` could.
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Robert Bennett via swift-evolution]

Instead of adding “@autoclosure ()->Never” to ??, why not make that the role of 
!! ? This would both make it clear that the unwrap is unsafe, like !, but also 
provide flexibility in how to report the error. E.G., optional !! 
fatalError(“oops”) 

> On Jun 28, 2017, at 11:41 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Count me in as a strong proponent of ?? () -> Never. We don't need to burden 
>> the language with an extra operator just for that.
> 
> You could say the same about ??
> 
> The concern that an additional operator (and one that, IMO, fits well into 
> existing patterns) is so burdensome seems way overweighted in this discussion 
> IMO. 
> 
> Adding the operator, and encouraging its use, will help foster better 
> understanding of optionals and legitimate use of force-unwrapping in a way 
> that I don’t think `?? fatalError` could.
> 
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Ben Cohen via swift-evolution]

> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution 
>  wrote:
> 
> Count me in as a strong proponent of ?? () -> Never. We don't need to burden 
> the language with an extra operator just for that.

You could say the same about ??

The concern that an additional operator (and one that, IMO, fits well into 
existing patterns) is so burdensome seems way overweighted in this discussion 
IMO. 

Adding the operator, and encouraging its use, will help foster better 
understanding of optionals and legitimate use of force-unwrapping in a way that 
I don’t think `?? fatalError` could.


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Ben Cohen via swift-evolution]

> On Jun 28, 2017, at 6:03 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
> argue both ways, with the goal in reading code as "unwrap or die".
> 


Personally, I strongly prefer `foo !! "explanation"` over `foo ?? 
fatalError()`. I don’t think adding another operator for what is a very common 
need is a concern, and is easier to read at a glance than the ??/fatalError 
combo.  There is a bit of cognitive dissonance between ??, a normally-fluffy 
nonthreatening defaulting operator, and fatalError, a scary beware operator. 
`!!` OTOH matches `!` in clearly flagging the unwrap as unsafe and that your 
program will exit. I also think it would be easier to explain `!!` to beginners 
as part of a wider story explaining optionals in general, unwraps, what `nil` 
means and what `!` means etc. Whereas `foo ?? Never` requires a lot of heavy 
lifting to understand how/why it works – we might all understand it, but that 
understanding is built on a lot of foundational understanding.

I also think a `Never` type would be very useful. Just that for this particular 
case, `!!` is still worth adding too.


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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 28 Jun 2017, at 15:03, Erica Sadun via swift-evolution 
>  wrote:
> 
> I'll give this a kick around as soon as I get a moment and revise. I am 
> slightly concerned that we discussed variations of this in the past (throwing 
> if memory serves, with `Error` on the rhs) and that it broke the expectations 
> of nil-coalescing. 
> 
> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
> argue both ways, with the goal in reading code as "unwrap or die".
> 
> -- E

Count me in as a strong proponent of ?? () -> Never. We don't need to burden 
the language with an extra operator just for that.

>> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution 
>>  wrote:
>> 
>> The compatibility testing revealed no related errors. And the full test 
>> suite only shows one that I listed already.
>> 
>> Max
>> 
>> 
>>> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu  wrote:
>>> 
>>> This solution is nifty indeed, and has the chief advantage of working.
>>> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution 
>>>  wrote:
> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev 
>  wrote:
> 
> How about?
> 
> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws 
> -> Never) rethrows -> T {
> switch optional {
> case .some(let value):
> return value
> case .none:
> try noreturnOrError()
> }
> }
> 
 
 Yeah, I saw your email right after I sent mine =)
 This works, I tried it and also ran the test suite. There was only one 
 error.
 
   var s: String = ns ?? "str" as String as String // 
 expected-error{{cannot convert value of type 'NSString?' to expected 
 argument type 'String?'}}
  
 ^~~~
  
 cannot convert value of type 'String' to expected argument type 'NSString'
 
 
 I now wonder what the effect on the source compatibility suite would be:
 https://github.com/apple/swift/pull/10639
 
 
 Max
 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> 
>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> As you write, this operator becomes sugar for “?? fatalError()” once 
>>> Never becomes a true bottom type.
>>> 
>>> In the meantime, can’t the same thing be accomplished by overloading 
>>> fatalError so it’s a generic function that returns a discardable result 
>>> of type T, which in turn calls the Never-returning overload?
>> 
>> I like this idea more than adding an extra operator, but overloading 
>> fatalError won’t work now because of 
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>> 
>> 
>> 
>> 
 On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
  wrote:
 Using an operator to provide feedback on the context of a failed 
 unwrap has become a commonly implemented approach in the Swift 
 developer Community. What are your thoughts about adopting this 
 widely-used operator into the standard library?
 
 guard !lastItem.isEmpty else { return }
 let lastItem = array.last !! "Array must be non-empty"
 
 Details here:  
 https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
 
 Thank you for your thoughtful feedback, -- E
 
 ___
 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
>> 
>> ___
>> 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 maili

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

> On Jun 28, 2017, at 3:52 AM, Yuta Koshizawa via swift-evolution 
>  wrote:
> 
> Hi, I think it is an orthogonal issue if we need a new operator. It is
> also possible to introduce an infix `!` for it.
> 
> I am sure that we do not need to avoid `precondition` as long as we
> use it appropriately. It is useful to realize consistent behavior with
> `Array`'s `subscript`, forced unwrapping `!`, `&+` and so on. In this
> context, `precondition` does not mean a general word "precondition"
> but the `precondition` function in the Swift standard library, which
> is removed when -Ounchecked.


How would the line run then? Would it simply act as a forced unwrapped under 
-Ounchecked? 

-- E

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

>From that point of view, shouldn’t we then be talking about removing the 
>postfix unary operator “!”? With this proposal it could just as easily be 
>replaced with: ?? fatalError(“failed nil check”). But I don’t think anyone 
>would take that suggestion seriously, so why are we not taking the idea of !! 
>seriously either?

I really like the idea of having both:

let last = array.last ?? fatalError(“Reason”) // () → Never
let last = array.last !! “Reason”

The first one fits with the idea of Nil Coalescing and explicitly failing 
because of a precondition failure. Or as Tony put it, it “leaves no other 
choice … but to do something that dies”. It leaves open the case of having the 
error removed at certain -O levels.

The second one fits with the idea of logical failure where the operator itself 
is doing the dying, just like the unary version. And, like the force unwrap 
operator, it wouldn’t be removed at -Ounchecked.

Dave

> On Jun 28, 2017, at 7:08 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> The idea behind `?? () -> Never` is that it leaves no other choice in the nil 
> case but to do something that dies, and that something is typically a 
> function call like fatalError() that documents well enough the dying so !! 
> would be unnecessary. And since it was pointed out above that this can be 
> done today in the language with an autoclosure, I strongly believe that's the 
> direction we should go vs. defining a new operator.
> 
> In other words, !! doesn't fit with Never because it's not the *operator* 
> that's doing the dying, but the right-hand side of that operator.
> 
> On Wed, Jun 28, 2017 at 6:04 AM Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I'll give this a kick around as soon as I get a moment and revise. I am 
> slightly concerned that we discussed variations of this in the past (throwing 
> if memory serves, with `Error` on the rhs) and that it broke the expectations 
> of nil-coalescing. 
> 
> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
> argue both ways, with the goal in reading code as "unwrap or die".
> 
> -- E
> 
>> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> The compatibility testing revealed no related errors. And the full test 
>> suite only shows one that I listed already.
>> 
>> Max
>> 
>> 
>>> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu >> > wrote:
>>> 
>>> This solution is nifty indeed, and has the chief advantage of working.
>>> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
 On Jun 27, 2017, at 1:03 PM, Adrian Zubarev 
 mailto:adrian.zuba...@devandartist.com>> 
 wrote:
 
 How about?
 
 public func ?? (optional: T?, noreturnOrError: @autoclosure () throws 
 -> Never) rethrows -> T {
 switch optional {
 case .some(let value):
 return value
 case .none:
 try noreturnOrError()
 }
 }
 
>>> 
>>> Yeah, I saw your email right after I sent mine =)
>>> This works, I tried it and also ran the test suite. There was only one 
>>> error.
>>> 
>>>   var s: String = ns ?? "str" as String as String // expected-error{{cannot 
>>> convert value of type 'NSString?' to expected argument type 'String?'}}
>>>  
>>> ^~~~
>>>  cannot 
>>> convert value of type 'String' to expected argument type 'NSString'
>>> 
>>> 
>>> I now wonder what the effect on the source compatibility suite would be:
>>> https://github.com/apple/swift/pull/10639 
>>> 
>>> 
>>> 
>>> Max
>>> 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> 
>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> As you write, this operator becomes sugar for “?? fatalError()” once 
>> Never becomes a true bottom type.
>> 
>> In the meantime, can’t the same thing be accomplished by overloading 
>> fatalError so it’s a generic function that returns a discardable result 
>> of type T, which in turn calls the Never-returning overload?
> 
> I like this idea more than adding an extra operator, but overloading 
> fatalError won’t work now because of 
> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>  
> 
> 
> 
> 
> 
>> On Tue, Jun 27, 2017 at 12:25 Eri

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Tony Allevato via swift-evolution]

The idea behind `?? () -> Never` is that it leaves no other choice in the
nil case but to do something that dies, and that something is typically a
function call like fatalError() that documents well enough the dying so !!
would be unnecessary. And since it was pointed out above that this can be
done today in the language with an autoclosure, I strongly believe that's
the direction we should go vs. defining a new operator.

In other words, !! doesn't fit with Never because it's not the *operator*
that's doing the dying, but the right-hand side of that operator.

On Wed, Jun 28, 2017 at 6:04 AM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> I'll give this a kick around as soon as I get a moment and revise. I am
> slightly concerned that we discussed variations of this in the past
> (throwing if memory serves, with `Error` on the rhs) and that it broke the
> expectations of nil-coalescing.
>
> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I
> can argue both ways, with the goal in reading code as "unwrap or die".
>
> -- E
>
> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The compatibility testing revealed no related errors. And the full test
> suite only shows one that I listed already.
>
> Max
>
>
> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu  wrote:
>
> This solution is nifty indeed, and has the chief advantage of working.
> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev <
>> adrian.zuba...@devandartist.com> wrote:
>>
>> How about?
>>
>> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
>> Never) rethrows -> T {
>> switch optional {
>> case .some(let value):
>> return value
>> case .none:
>> try noreturnOrError()
>> }
>> }
>>
>>
>> Yeah, I saw your email right after I sent mine =)
>> This works, I tried it and also ran the test suite. There was only one
>> error.
>>
>>   var s: String = ns ?? "str" as String as String //
>> expected-error{{cannot convert value of type 'NSString?' to expected
>> argument type 'String?'}}
>>
>>  ^~~~
>>
>>  cannot convert value of type 'String' to expected argument type 'NSString'
>>
>>
>> I now wonder what the effect on the source compatibility suite would be:
>> https://github.com/apple/swift/pull/10639
>>
>>
>> Max
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>>
>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> As you write, this operator becomes sugar for “?? fatalError()” once
>> Never becomes a true bottom type.
>>
>> In the meantime, can’t the same thing be accomplished by overloading
>> fatalError so it’s a generic function that returns a discardable result of
>> type T, which in turn calls the Never-returning overload?
>>
>>
>> I like this idea more than adding an extra operator, but overloading
>> fatalError won’t work now because of
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>>
>>
>>
>>
>> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Using an operator to provide feedback on the context of a failed unwrap
>>> has become a commonly implemented approach in the Swift developer
>>> Community. What are your thoughts about adopting this widely-used operator
>>> into the standard library?
>>>
>>> guard !lastItem.isEmpty else { return }
>>> let lastItem = array.last !! "Array must be non-empty"
>>>
>>> Details here:
>>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>>>
>>> Thank you for your thoughtful feedback, -- E
>>>
>>> ___
>>> 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
>>
>
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

I'll give this a kick around as soon as I get a moment and revise. I am 
slightly concerned that we discussed variations of this in the past (throwing 
if memory serves, with `Error` on the rhs) and that it broke the expectations 
of nil-coalescing. 

In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
argue both ways, with the goal in reading code as "unwrap or die".

-- E

> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution 
>  wrote:
> 
> The compatibility testing revealed no related errors. And the full test suite 
> only shows one that I listed already.
> 
> Max
> 
> 
>> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu > > wrote:
>> 
>> This solution is nifty indeed, and has the chief advantage of working.
>> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev 
>>> mailto:adrian.zuba...@devandartist.com>> 
>>> wrote:
>>> 
>>> How about?
>>> 
>>> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
>>> Never) rethrows -> T {
>>> switch optional {
>>> case .some(let value):
>>> return value
>>> case .none:
>>> try noreturnOrError()
>>> }
>>> }
>>> 
>> 
>> Yeah, I saw your email right after I sent mine =)
>> This works, I tried it and also ran the test suite. There was only one error.
>> 
>>   var s: String = ns ?? "str" as String as String // expected-error{{cannot 
>> convert value of type 'NSString?' to expected argument type 'String?'}}
>>  
>> ^~~~
>>  cannot 
>> convert value of type 'String' to expected argument type 'NSString'
>> 
>> 
>> I now wonder what the effect on the source compatibility suite would be:
>> https://github.com/apple/swift/pull/10639 
>> 
>> 
>> 
>> Max
>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 
> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> As you write, this operator becomes sugar for “?? fatalError()” once 
> Never becomes a true bottom type.
> 
> In the meantime, can’t the same thing be accomplished by overloading 
> fatalError so it’s a generic function that returns a discardable result 
> of type T, which in turn calls the Never-returning overload?
 
 I like this idea more than adding an extra operator, but overloading 
 fatalError won’t work now because of 
 https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
  
 
 
 
 
 
> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Using an operator to provide feedback on the context of a failed unwrap 
> has become a commonly implemented approach in the Swift developer 
> Community. What are your thoughts about adopting this widely-used 
> operator into the standard library?
> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:  
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> 
> 
> Thank you for your thoughtful feedback, -- E
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Yuta Koshizawa via swift-evolution]

Hi, I think it is an orthogonal issue if we need a new operator. It is
also possible to introduce an infix `!` for it.

I am sure that we do not need to avoid `precondition` as long as we
use it appropriately. It is useful to realize consistent behavior with
`Array`'s `subscript`, forced unwrapping `!`, `&+` and so on. In this
context, `precondition` does not mean a general word "precondition"
but the `precondition` function in the Swift standard library, which
is removed when -Ounchecked.

However I noticed the possibility that -Ounchecked removed the `nil`
check by `??` in the following code using `preconditionFailure` as a
clue of the optimization.

let bar: Foo = optionalFoo ?? preconditionFailure("Reason why you
are sure that `optionalFoo` is not nil")

So now I think using `?? preconditionFailure(message)` with `Never` as
a bottom type is preferable to `!!` even in a standpoint of
-Ounckecked.

--
Yuta


2017-06-28 15:52 GMT+09:00 Elviro Rocca :
> Yep, "logic" failures are not supposed to be there if not for avoiding
> checks that could worsen performance in pieces of code that should run as
> fast as possible. I like Adrian's solution because it doesn't add a new
> operator to the standard library, something that could mean one more
> encouragement to force unwrap things.
>
> About preconditions, Cocoa with Love's Matt Gallagher wrote an article some
> months ago on partial functions, why you should avoid them and how to do so:
> it's a very interesting read
> http://www.cocoawithlove.com/blog/2016/01/25/partial-functions-part-one-avoidance.html
>
>
> Elviro
>
> Il giorno 28 giu 2017, alle ore 07:02, Yuta Koshizawa via swift-evolution
>  ha scritto:
>
> ...
>
> Logic failures are intended to be handled by fixing the code. It means
> checks of logic failures can be removed if the code is tested enough.
> Actually checks of logic failures for various operations, `!`,
> `array[i]`, `&+` and so on, are designed and implemented to be removed
> when we use `-Ounchecked`. It is useful for heavy computation like
> image processing and machine learning in which overhead of those
> checks is not permissible.
>
> So I think checks for `!!` should be removed with `-Ounchecked` as well.
>
> --
> Yuta
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Elviro Rocca via swift-evolution]

Yep, "logic" failures are not supposed to be there if not for avoiding checks 
that could worsen performance in pieces of code that should run as fast as 
possible. I like Adrian's solution because it doesn't add a new operator to the 
standard library, something that could mean one more encouragement to force 
unwrap things.

About preconditions, Cocoa with Love's Matt Gallagher wrote an article some 
months ago on partial functions, why you should avoid them and how to do so: 
it's a very interesting read 
http://www.cocoawithlove.com/blog/2016/01/25/partial-functions-part-one-avoidance.html
 



Elviro

> Il giorno 28 giu 2017, alle ore 07:02, Yuta Koshizawa via swift-evolution 
>  ha scritto:
> 
> ...
> 
> Logic failures are intended to be handled by fixing the code. It means
> checks of logic failures can be removed if the code is tested enough.
> Actually checks of logic failures for various operations, `!`,
> `array[i]`, `&+` and so on, are designed and implemented to be removed
> when we use `-Ounchecked`. It is useful for heavy computation like
> image processing and machine learning in which overhead of those
> checks is not permissible.
> 
> So I think checks for `!!` should be removed with `-Ounchecked` as well.
> 
> --
> Yuta
> 

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Yuta Koshizawa via swift-evolution]

I like it, but I think the implementation can be improved like below.

public static func !!(optional: Optional, errorMessage:
@autoclosure () -> String) -> Wrapped {
precondition(optional != nil, errorMessage())
return optional!
}

Failures of forced unwrapping are "logic failures" and I think it is
same about `!!`.

https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures

Logic failures are intended to be handled by fixing the code. It means
checks of logic failures can be removed if the code is tested enough.
Actually checks of logic failures for various operations, `!`,
`array[i]`, `&+` and so on, are designed and implemented to be removed
when we use `-Ounchecked`. It is useful for heavy computation like
image processing and machine learning in which overhead of those
checks is not permissible.

So I think checks for `!!` should be removed with `-Ounchecked` as well.

--
Yuta


2017-06-28 2:16 GMT+09:00 Erica Sadun via swift-evolution
:
> Using an operator to provide feedback on the context of a failed unwrap has
> become a commonly implemented approach in the Swift developer Community.
> What are your thoughts about adopting this widely-used operator into the
> standard library?
>
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
>
> Details here:
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>
> Thank you for your thoughtful feedback, -- E
>
>
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Max Moiseev via swift-evolution]

The compatibility testing revealed no related errors. And the full test suite 
only shows one that I listed already.

Max


> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu  wrote:
> 
> This solution is nifty indeed, and has the chief advantage of working.
> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev > > wrote:
>> 
>> How about?
>> 
>> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
>> Never) rethrows -> T {
>> switch optional {
>> case .some(let value):
>> return value
>> case .none:
>> try noreturnOrError()
>> }
>> }
>> 
> 
> Yeah, I saw your email right after I sent mine =)
> This works, I tried it and also ran the test suite. There was only one error.
> 
>   var s: String = ns ?? "str" as String as String // expected-error{{cannot 
> convert value of type 'NSString?' to expected argument type 'String?'}}
>  
> ^~~~
>  cannot 
> convert value of type 'String' to expected argument type 'NSString'
> 
> 
> I now wonder what the effect on the source compatibility suite would be:
> https://github.com/apple/swift/pull/10639 
> 
> 
> 
> Max
> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> 
 On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 As you write, this operator becomes sugar for “?? fatalError()” once Never 
 becomes a true bottom type.
 
 In the meantime, can’t the same thing be accomplished by overloading 
 fatalError so it’s a generic function that returns a discardable result of 
 type T, which in turn calls the Never-returning overload?
>>> 
>>> I like this idea more than adding an extra operator, but overloading 
>>> fatalError won’t work now because of 
>>> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>>>  
>>> 
>>> 
>>> 
>>> 
>>> 
 On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 Using an operator to provide feedback on the context of a failed unwrap 
 has become a commonly implemented approach in the Swift developer 
 Community. What are your thoughts about adopting this widely-used operator 
 into the standard library?
 
 guard !lastItem.isEmpty else { return }
 let lastItem = array.last !! "Array must be non-empty"
 
 Details here:  
 https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
 
 
 Thank you for your thoughtful feedback, -- E
 
 ___
 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 
> 

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu via swift-evolution]

This solution is nifty indeed, and has the chief advantage of working.
On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
> How about?
>
> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
> Never) rethrows -> T {
> switch optional {
> case .some(let value):
> return value
> case .none:
> try noreturnOrError()
> }
> }
>
>
> Yeah, I saw your email right after I sent mine =)
> This works, I tried it and also ran the test suite. There was only one
> error.
>
>   var s: String = ns ?? "str" as String as String //
> expected-error{{cannot convert value of type 'NSString?' to expected
> argument type 'String?'}}
>
>  ^~~~
>
>  cannot convert value of type 'String' to expected argument type 'NSString'
>
>
> I now wonder what the effect on the source compatibility suite would be:
> https://github.com/apple/swift/pull/10639
>
>
> Max
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>
> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> As you write, this operator becomes sugar for “?? fatalError()” once Never
> becomes a true bottom type.
>
> In the meantime, can’t the same thing be accomplished by overloading
> fatalError so it’s a generic function that returns a discardable result of
> type T, which in turn calls the Never-returning overload?
>
>
> I like this idea more than adding an extra operator, but overloading
> fatalError won’t work now because of
> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>
>
>
>
> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Using an operator to provide feedback on the context of a failed unwrap
>> has become a commonly implemented approach in the Swift developer
>> Community. What are your thoughts about adopting this widely-used operator
>> into the standard library?
>>
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>>
>> Details here:
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>>
>> Thank you for your thoughtful feedback, -- E
>>
>> ___
>> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Max Moiseev via swift-evolution]

> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev  
> wrote:
> 
> How about?
> 
> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
> Never) rethrows -> T {
> switch optional {
> case .some(let value):
> return value
> case .none:
> try noreturnOrError()
> }
> }
> 
Yeah, I saw your email right after I sent mine =)
This works, I tried it and also ran the test suite. There was only one error.

  var s: String = ns ?? "str" as String as String // expected-error{{cannot 
convert value of type 'NSString?' to expected argument type 'String?'}}
 
^~~~
 cannot 
convert value of type 'String' to expected argument type 'NSString'


I now wonder what the effect on the source compatibility suite would be:
https://github.com/apple/swift/pull/10639 



Max

> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> As you write, this operator becomes sugar for “?? fatalError()” once Never 
>>> becomes a true bottom type.
>>> 
>>> In the meantime, can’t the same thing be accomplished by overloading 
>>> fatalError so it’s a generic function that returns a discardable result of 
>>> type T, which in turn calls the Never-returning overload?
>> 
>> I like this idea more than adding an extra operator, but overloading 
>> fatalError won’t work now because of 
>> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>>  
>> 
>> 
>> 
>> 
>> 
>>> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> Using an operator to provide feedback on the context of a failed unwrap has 
>>> become a commonly implemented approach in the Swift developer Community. 
>>> What are your thoughts about adopting this widely-used operator into the 
>>> standard library?
>>> 
>>> guard !lastItem.isEmpty else { return }
>>> let lastItem = array.last !! "Array must be non-empty"
>>> 
>>> Details here:  
>>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>>> 
>>> 
>>> Thank you for your thoughtful feedback, -- E
>>> 
>>> ___
>>> 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] Introducing the "Unwrap or Die" operator to the standard library

[Erica Sadun via swift-evolution]

> On Jun 27, 2017, at 1:51 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2017, at 1:43 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I agree with Jaden and Xiaodi above—making Never a proper bottom type and 
>> using ?? would accomplish the same thing, and it's more general because it 
>> doesn't imply fatalError.
>> 
>> IMO, I don't think we should be making it *easier* to hide traps in our 
>> code. I don't think having to write a full guard/fatalError is all that bad 
>> a thing—on the contrary, I want major failure points to stick out when I 
>> read code. That being said, if some users want something like this, Never + 
>> ?? would get us there with something already planned for the language, 
>> rather than introducing a new operator (for which the bar should be set 
>> high).
> 
> I disagree that this is making hiding traps easier. It’s asking you to put in 
> two exclamation points instead of only one to force unwrap, along with an 
> explanation of why you think it’s ok to be doing so. That’s much more “in 
> your face” than “array.last!”.
> 
> Dave

This ties in pretty closely with my goals for the "roles" proposal. I want 
Swift to evolve towards clarifying developer intent both for code inspection 
and compilation support.

I honestly wouldn't mind having both solutions available.

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

How about?

public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
Never) rethrows -> T {
switch optional {
case .some(let value):
return value
case .none:
try noreturnOrError()
}
}


-- 
Adrian Zubarev
Sent with Airmail

Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
(swift-evolution@swift.org) schrieb:


On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
 wrote:

As you write, this operator becomes sugar for “?? fatalError()” once Never 
becomes a true bottom type.

In the meantime, can’t the same thing be accomplished by overloading fatalError 
so it’s a generic function that returns a discardable result of type T, which 
in turn calls the Never-returning overload?

I like this idea more than adding an extra operator, but overloading fatalError 
won’t work now because of 
https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668




On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
 wrote:
Using an operator to provide feedback on the context of a failed unwrap has 
become a commonly implemented approach in the Swift developer Community. What 
are your thoughts about adopting this widely-used operator into the standard 
library?

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b

Thank you for your thoughtful feedback, -- E

___
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] Introducing the "Unwrap or Die" operator to the standard library

[Max Moiseev via swift-evolution]

> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> As you write, this operator becomes sugar for “?? fatalError()” once Never 
> becomes a true bottom type.
> 
> In the meantime, can’t the same thing be accomplished by overloading 
> fatalError so it’s a generic function that returns a discardable result of 
> type T, which in turn calls the Never-returning overload?

I like this idea more than adding an extra operator, but overloading fatalError 
won’t work now because of 
https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
 





> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Using an operator to provide feedback on the context of a failed unwrap has 
> become a commonly implemented approach in the Swift developer Community. What 
> are your thoughts about adopting this widely-used operator into the standard 
> library?
> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> 
> 
> Thank you for your thoughtful feedback, -- E
> 
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Adrian Zubarev via swift-evolution]

Can’t we simply overload ?? to support @autoclosure () -> Never now and remove 
that overload when Never is the bottom type? Syntactically it would look and do 
the same.



-- 
Adrian Zubarev
Sent with Airmail

Am 27. Juni 2017 um 21:52:01, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:


On Jun 27, 2017, at 2:49 PM, David Hart via swift-evolution 
 wrote:


On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution 
 wrote:

Also a +1 from me. This is something I always put in to my code.

I agree that having `Never` as a bottom type is interesting, but even if that 
were the case, the proposed “!!” operator is still useful, because it 
short-circuits having to fatalError() myself. IE:

let last = array.last ?? fatalError(“array must not be empty”)

The above solution with Never is the better solution IMHO:

No new operator
More flexible: what if you want something else than a fatalError? For example, 
I might want to define a logAndFatalError() function which stores the error to 
a log file before trapping.

+1


vs

let last = array.last !! “Array must not be empty"

I also think having it “fatalError” in shipping code is fine, because it’s 
equivalent to what would happen if you incorrect force-unwrap.

Dave

On Jun 27, 2017, at 12:08 PM, Zach Waldowski via swift-evolution 
 wrote:

Big +1.

Using `!` is widely seen as a smell. However, the need for it still arises; 
they are preconditions, of a sort. It has become prevalent in my teams’ 
codebases to do “guard else preconditionFailure”.

I like `!!` over something like `?!`; it follows the pattern that almost every 
`?` in the language has an equivalent `!`.

The implementation details are ultimately not relevant to me. I’m a fan of 
`Never` being a bottom type for more reasons than just this. I also see no 
reason why operator funcs couldn’t accept file and line as extra arguments on 
the rhs.

Best,
  Zachary Waldowski
  z...@waldowski.me

On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:
Using an operator to provide feedback on the context of a failed unwrap has 
become a commonly implemented approach in the Swift developer Community. What 
are your thoughts about adopting this widely-used operator into the standard 
library?

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b

Thank you for your thoughtful feedback, -- E

___
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

___
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] Introducing the "Unwrap or Die" operator to the standard library

[Matthew Johnson via swift-evolution]

> On Jun 27, 2017, at 2:49 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Also a +1 from me. This is something I always put in to my code.
>> 
>> I agree that having `Never` as a bottom type is interesting, but even if 
>> that were the case, the proposed “!!” operator is still useful, because it 
>> short-circuits having to fatalError() myself. IE:
>> 
>> let last = array.last ?? fatalError(“array must not be empty”)
> 
> The above solution with Never is the better solution IMHO:
> 
> No new operator
> More flexible: what if you want something else than a fatalError? For 
> example, I might want to define a logAndFatalError() function which stores 
> the error to a log file before trapping.

+1

> 
>> vs
>> 
>> let last = array.last !! “Array must not be empty"
>> 
>> I also think having it “fatalError” in shipping code is fine, because it’s 
>> equivalent to what would happen if you incorrect force-unwrap.
>> 
>> Dave
>> 
>>> On Jun 27, 2017, at 12:08 PM, Zach Waldowski via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Big +1.
>>> 
>>> Using `!` is widely seen as a smell. However, the need for it still arises; 
>>> they are preconditions, of a sort. It has become prevalent in my teams’ 
>>> codebases to do “guard else preconditionFailure”.
>>> 
>>> I like `!!` over something like `?!`; it follows the pattern that almost 
>>> every `?` in the language has an equivalent `!`.
>>> 
>>> The implementation details are ultimately not relevant to me. I’m a fan of 
>>> `Never` being a bottom type for more reasons than just this. I also see no 
>>> reason why operator funcs couldn’t accept file and line as extra arguments 
>>> on the rhs.
>>> 
>>> Best,
>>>   Zachary Waldowski
>>>   z...@waldowski.me 
>>> 
>>> On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:
 Using an operator to provide feedback on the context of a failed unwrap 
 has become a commonly implemented approach in the Swift developer 
 Community. What are your thoughts about adopting this widely-used operator 
 into the standard library?
 
 guard !lastItem.isEmpty else { return }
 let lastItem = array.last !! "Array must be non-empty"
 
 Details here:  
 https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
 
 
 Thank you for your thoughtful feedback, -- E
 
 ___
 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

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

> On Jun 27, 2017, at 1:43 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> I agree with Jaden and Xiaodi above—making Never a proper bottom type and 
> using ?? would accomplish the same thing, and it's more general because it 
> doesn't imply fatalError.
> 
> IMO, I don't think we should be making it *easier* to hide traps in our code. 
> I don't think having to write a full guard/fatalError is all that bad a 
> thing—on the contrary, I want major failure points to stick out when I read 
> code. That being said, if some users want something like this, Never + ?? 
> would get us there with something already planned for the language, rather 
> than introducing a new operator (for which the bar should be set high).

I disagree that this is making hiding traps easier. It’s asking you to put in 
two exclamation points instead of only one to force unwrap, along with an 
explanation of why you think it’s ok to be doing so. That’s much more “in your 
face” than “array.last!”.

Dave


> On Tue, Jun 27, 2017 at 12:10 PM Paul Cantrell via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> > it gives me the creeps to leave something like ‘fatalError’ in a shipping 
> > application
> 
> 
> Agreed, and I would use it for _exactly_ this reason.
> 
> I avoid force unwrapping in production code, looking first for ways to 
> gracefully handle the situation. Whenever I do use !, there is careful 
> reasoning behind its use: “this is safe because p → q, and there is no 
> reasonable way to handle this error because it cannot happen.” I take care to 
> note this reasoning in a same-line comment, e.g.:
> 
>paramString.data(using: String.Encoding.ascii)!  // ASCII safe because 
> paramString already URL escaped
> 
> Such reasoning will, of course, eventually fail somewhere. It would be 
> helpful to get runtime diagnostics on such a failure:
> 
>paramString.data(using: String.Encoding.ascii) !! "URL escaped paramString 
> must be ASCII"
> 
> So Rien, I endorse this idea from the perspective of one who is !-averse.
> 
> Cheers, P
> 
> 
> > On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > I would not use it.
> > Somehow it gives me the creeps to leave something like ‘fatalError’ in a 
> > shipping application.
> > During development it could make sense, but then again I like to keep 
> > development and shipping the same as much as possible.
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl 
> > Blog: http://swiftrien.blogspot.com 
> > Github: http://github.com/Balancingrock 
> > Project: http://swiftfire.nl  - An HTTP(S) web server 
> > framework in Swift
> >
> >
> >
> >
> >
> >
> >
> >> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution 
> >> mailto:swift-evolution@swift.org>> wrote:
> >>
> >> Using an operator to provide feedback on the context of a failed unwrap 
> >> has become a commonly implemented approach in the Swift developer 
> >> Community. What are your thoughts about adopting this widely-used operator 
> >> into the standard library?
> >>
> >> guard !lastItem.isEmpty else { return }
> >> let lastItem = array.last !! "Array must be non-empty"
> >>
> >> Details here:  
> >> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
> >> 
> >>
> >> Thank you for your thoughtful feedback, -- E
> >>
> >> ___
> >> 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

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

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[David Hart via swift-evolution]

> On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution 
>  wrote:
> 
> Also a +1 from me. This is something I always put in to my code.
> 
> I agree that having `Never` as a bottom type is interesting, but even if that 
> were the case, the proposed “!!” operator is still useful, because it 
> short-circuits having to fatalError() myself. IE:
> 
> let last = array.last ?? fatalError(“array must not be empty”)

The above solution with Never is the better solution IMHO:

No new operator
More flexible: what if you want something else than a fatalError? For example, 
I might want to define a logAndFatalError() function which stores the error to 
a log file before trapping.

> vs
> 
> let last = array.last !! “Array must not be empty"
> 
> I also think having it “fatalError” in shipping code is fine, because it’s 
> equivalent to what would happen if you incorrect force-unwrap.
> 
> Dave
> 
>> On Jun 27, 2017, at 12:08 PM, Zach Waldowski via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Big +1.
>> 
>> Using `!` is widely seen as a smell. However, the need for it still arises; 
>> they are preconditions, of a sort. It has become prevalent in my teams’ 
>> codebases to do “guard else preconditionFailure”.
>> 
>> I like `!!` over something like `?!`; it follows the pattern that almost 
>> every `?` in the language has an equivalent `!`.
>> 
>> The implementation details are ultimately not relevant to me. I’m a fan of 
>> `Never` being a bottom type for more reasons than just this. I also see no 
>> reason why operator funcs couldn’t accept file and line as extra arguments 
>> on the rhs.
>> 
>> Best,
>>   Zachary Waldowski
>>   z...@waldowski.me 
>> 
>> On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:
>>> Using an operator to provide feedback on the context of a failed unwrap has 
>>> become a commonly implemented approach in the Swift developer Community. 
>>> What are your thoughts about adopting this widely-used operator into the 
>>> standard library?
>>> 
>>> guard !lastItem.isEmpty else { return }
>>> let lastItem = array.last !! "Array must be non-empty"
>>> 
>>> Details here:  
>>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>>> 
>>> 
>>> Thank you for your thoughtful feedback, -- E
>>> 
>>> ___
>>> 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] Introducing the "Unwrap or Die" operator to the standard library

[Tony Allevato via swift-evolution]

I agree with Jaden and Xiaodi above—making Never a proper bottom type and
using ?? would accomplish the same thing, and it's more general because it
doesn't imply fatalError.

IMO, I don't think we should be making it *easier* to hide traps in our
code. I don't think having to write a full guard/fatalError is all that bad
a thing—on the contrary, I want major failure points to stick out when I
read code. That being said, if some users want something like this, Never +
?? would get us there with something already planned for the language,
rather than introducing a new operator (for which the bar should be set
high).
On Tue, Jun 27, 2017 at 12:10 PM Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

> > it gives me the creeps to leave something like ‘fatalError’ in a
> shipping application
>
>
> Agreed, and I would use it for _exactly_ this reason.
>
> I avoid force unwrapping in production code, looking first for ways to
> gracefully handle the situation. Whenever I do use !, there is careful
> reasoning behind its use: “this is safe because p → q, and there is no
> reasonable way to handle this error because it cannot happen.” I take care
> to note this reasoning in a same-line comment, e.g.:
>
>paramString.data(using: String.Encoding.ascii)!  // ASCII safe because
> paramString already URL escaped
>
> Such reasoning will, of course, eventually fail somewhere. It would be
> helpful to get runtime diagnostics on such a failure:
>
>paramString.data(using: String.Encoding.ascii) !! "URL escaped
> paramString must be ASCII"
>
> So Rien, I endorse this idea from the perspective of one who is !-averse.
>
> Cheers, P
>
>
> > On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I would not use it.
> > Somehow it gives me the creeps to leave something like ‘fatalError’ in a
> shipping application.
> > During development it could make sense, but then again I like to keep
> development and shipping the same as much as possible.
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Balancingrock
> > Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> >
> >
> >
> >
> >
> >
> >
> >> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Using an operator to provide feedback on the context of a failed unwrap
> has become a commonly implemented approach in the Swift developer
> Community. What are your thoughts about adopting this widely-used operator
> into the standard library?
> >>
> >> guard !lastItem.isEmpty else { return }
> >> let lastItem = array.last !! "Array must be non-empty"
> >>
> >> Details here:
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
> >>
> >> Thank you for your thoughtful feedback, -- E
> >>
> >> ___
> >> 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] Introducing the "Unwrap or Die" operator to the standard library

[Paul Cantrell via swift-evolution]

> it gives me the creeps to leave something like ‘fatalError’ in a shipping 
> application


Agreed, and I would use it for _exactly_ this reason.

I avoid force unwrapping in production code, looking first for ways to 
gracefully handle the situation. Whenever I do use !, there is careful 
reasoning behind its use: “this is safe because p → q, and there is no 
reasonable way to handle this error because it cannot happen.” I take care to 
note this reasoning in a same-line comment, e.g.:

   paramString.data(using: String.Encoding.ascii)!  // ASCII safe because 
paramString already URL escaped

Such reasoning will, of course, eventually fail somewhere. It would be helpful 
to get runtime diagnostics on such a failure:

   paramString.data(using: String.Encoding.ascii) !! "URL escaped paramString 
must be ASCII"

So Rien, I endorse this idea from the perspective of one who is !-averse.

Cheers, P


> On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution 
>  wrote:
> 
> I would not use it.
> Somehow it gives me the creeps to leave something like ‘fatalError’ in a 
> shipping application.
> During development it could make sense, but then again I like to keep 
> development and shipping the same as much as possible.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> 
> 
> 
> 
> 
> 
> 
>> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
>> 
>> Thank you for your thoughtful feedback, -- E
>> 
>> ___
>> 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] Introducing the "Unwrap or Die" operator to the standard library

[Dave DeLong via swift-evolution]

Also a +1 from me. This is something I always put in to my code.

I agree that having `Never` as a bottom type is interesting, but even if that 
were the case, the proposed “!!” operator is still useful, because it 
short-circuits having to fatalError() myself. IE:

let last = array.last ?? fatalError(“array must not be empty”)

vs

let last = array.last !! “Array must not be empty"

I also think having it “fatalError” in shipping code is fine, because it’s 
equivalent to what would happen if you incorrect force-unwrap.

Dave

> On Jun 27, 2017, at 12:08 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> Big +1.
> 
> Using `!` is widely seen as a smell. However, the need for it still arises; 
> they are preconditions, of a sort. It has become prevalent in my teams’ 
> codebases to do “guard else preconditionFailure”.
> 
> I like `!!` over something like `?!`; it follows the pattern that almost 
> every `?` in the language has an equivalent `!`.
> 
> The implementation details are ultimately not relevant to me. I’m a fan of 
> `Never` being a bottom type for more reasons than just this. I also see no 
> reason why operator funcs couldn’t accept file and line as extra arguments on 
> the rhs.
> 
> Best,
>   Zachary Waldowski
>   z...@waldowski.me 
> 
> On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:
>> Using an operator to provide feedback on the context of a failed unwrap has 
>> become a commonly implemented approach in the Swift developer Community. 
>> What are your thoughts about adopting this widely-used operator into the 
>> standard library?
>> 
>> guard !lastItem.isEmpty else { return }
>> let lastItem = array.last !! "Array must be non-empty"
>> 
>> Details here:  
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> 
>> 
>> Thank you for your thoughtful feedback, -- E
>> 
>> ___
>> 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] Introducing the "Unwrap or Die" operator to the standard library

[Zach Waldowski via swift-evolution]

Big +1.

Using `!` is widely seen as a smell. However, the need for it still
arises; they are preconditions, of a sort. It has become prevalent in my
teams’ codebases to do “guard else preconditionFailure”.
I like `!!` over something like `?!`; it follows the pattern that almost
every `?` in the language has an equivalent `!`.
The implementation details are ultimately not relevant to me. I’m a fan
of `Never` being a bottom type for more reasons than just this. I also
see no reason why operator funcs couldn’t accept file and line as extra
arguments on the rhs.
Best,
  Zachary Waldowski
  z...@waldowski.me

On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:> 
Using an operator to provide feedback on the context of a failed
> unwrap has become a commonly implemented approach in the Swift
> developer Community. What are your thoughts about adopting this widely-
> used operator into the standard library?> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b> 
> Thank you for your thoughtful feedback, -- E
> 
> _
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Jacob Bandes-Storch via swift-evolution]

I've found a similar thing useful, but with Errors instead of fatalErroring:

infix operator ?! : NilCoalescingPrecedence

func ?!(lhs: T?, rhs: @autoclosure () -> Error) throws -> T {
if let lhs = lhs { return lhs }
throw rhs()
}

let x = try failableFunc() ?! MyError.somethingFailed


On Tue, Jun 27, 2017 at 10:29 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 I had a slightly different implementation.
>
> https://gist.github.com/DevAndArtist/dad641ee833e60b02fd1db2dbb488c6a
>
> //
> // UnwrapOrTrap.swift
> //
> infix operator ?! : NilCoalescingPrecedence
>
> /// Performs a nil-coalescing operation, returning the wrapped value of an
> /// `Optional` instance or uses the rhs function to stop the program.
> ///
> /// - Parameters:
> ///   - optional: An optional value.
> ///   - noreturn: A function to stop the programm.
> func ?!(optional: T?, noreturn: @autoclosure () -> Never) -> T {
>switch optional {
>case .some(let value):
>   return value
>case .none:
>   noreturn()
>}
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 27. Juni 2017 um 19:25:15, Erica Sadun via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Using an operator to provide feedback on the context of a failed unwrap
> has become a commonly implemented approach in the Swift developer
> Community. What are your thoughts about adopting this widely-used operator
> into the standard library?
>
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
>
> Details here:  https://gist.github.com/erica/
> 423e4b1c63b95c4c90338cdff4939a9b
>
> Thank you for your thoughtful feedback, -- E
>
> ___
> 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] Introducing the "Unwrap or Die" operator to the standard library

[Rien via swift-evolution]

I would not use it.
Somehow it gives me the creeps to leave something like ‘fatalError’ in a 
shipping application.
During development it could make sense, but then again I like to keep 
development and shipping the same as much as possible.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift







> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution 
>  wrote:
> 
> Using an operator to provide feedback on the context of a failed unwrap has 
> become a commonly implemented approach in the Swift developer Community. What 
> are your thoughts about adopting this widely-used operator into the standard 
> library?
> 
> guard !lastItem.isEmpty else { return }
> let lastItem = array.last !! "Array must be non-empty"
> 
> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
> 
> Thank you for your thoughtful feedback, -- E
> 
> ___
> 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