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

> 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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

+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

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

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

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

> 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

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

> 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

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

> 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

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

"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:

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

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

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

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

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

> 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 >> > ha scritto: >> >> >>> On Jun 29,

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

> 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 >> > wrote: >> >> In the initial example, repeated here in largely

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

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

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

> 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: >> > >

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

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

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

> 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

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

> 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

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

> 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

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

> 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

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

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

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

>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

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

> 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

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

> 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

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

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

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

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: >

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

> 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: >> >>

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

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

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

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

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

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

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

> 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 >>

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

> 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

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

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

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

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

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

> 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

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

> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution > > 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

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

> 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

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

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*

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

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

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

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 >> > wrote: >> >> In the initial example, repeated here in largely

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

> 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

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

> On Jun 28, 2017, at 6:26 PM, Xiaodi Wu wrote: > > On Wed, Jun 28, 2017 at 5:05 PM, ilya via swift-evolution > > wrote: > One could, for example, extend the existing documentation markup sign /// to > pick up

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

> 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 >> > wrote: >> >> In the initial example, repeated here in

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

> 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

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

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

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

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

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

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

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

> On Jun 28, 2017, at 3:46 PM, Jordan Rose wrote: > > > >> On Jun 28, 2017, at 14:40, Erica Sadun via swift-evolution >> > wrote: >> >> The `!!` operator should follow the same semantics as >>

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

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

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

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

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

> 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

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

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

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

> 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 >>

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

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,

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

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

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

> 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 >> > wrote: >> >> In general, does everyone prefer `?? () -> Never`

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

> On 28 Jun 2017, at 17:41, Ben Cohen 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 >>

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

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

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

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`

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

> 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

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

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 >>

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

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

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

> 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

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

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

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

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

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

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

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

> 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

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

> 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 !!

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

> 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

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

>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

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

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

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

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 `?? () ->

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

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

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

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

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

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

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

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 ??

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

> 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

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

> 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 >> > wrote: >> >> I agree with Jaden and Xiaodi above—making

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

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

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

> 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 >

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

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

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

> 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

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

> 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. > >

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

> 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

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

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

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

> 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

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

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 ??

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

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

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

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

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

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:

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

+1 to Adrians implementation. While I like the sugar of both, I don’t think the operator should necessarily always cause a fatalError. Maybe we could use both the !! For some kind of fatal error and Adrians !? To just use @noreturn to leave the current function. > On Jun 27, 2017, at 11:29 AM,

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

+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

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

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

  1   2   >