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 <xiaodi...@gmail.com> 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 ?? <T>(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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
