[swift-evolution] Proposal: Replace ?? by an (optional) argument to ?

[Nikolai Vazquez]

The ?? operator is overloaded to take an optional as the second parameter already. So you can simply chain the ?? over and over with the the last being non optional, which will be the value of all others fail.

With that in mind, a firstNonOptional function wouldn't be hard to implement.

Sent from my iPad

> On Jan 29, 2016, at 9:25 AM, Ross O'Brien via swift-evolution <swift-evolution at swift.org> wrote:
> 
> What about it?
> 
> "x ?? false" is simple. If x isn't nil, return x; if x is nil, return false.
> "x?.isEmpty ?? false" again is already readable; if x isn't nil, return x.isEmpty; if x is nil, return false.
> 
> "Bool(x?.isEmpty)" seems be suggesting that the Bool type has a failable initialiser "init?(_: Bool?)". If x is nil, x.isEmpty would be nil, so the resulting Bool would be nil, not false - this code returns a Bool?, which you already had.
> 
> "??(false, x?.isEmpty)" ... uses an operator as an identifier, for a start. At best I'd try to interpret this like reduce - take a collection or variadic list of optionals, return the value of the first non-nil else return the "default". Except I'd still put the default at the end, because I can't think why it would be at the start.
> 
> So, if the given problem is taking the nil-coalescing and putting it up front, perhaps there should be a global generic function:
> 
> func firstNonOptional<T>(possibles:T?..., failsafe:T) -> T
> {
>     return possibles.reduce(nil, combine:{ $0 ?? $1 }) ?? failsafe
> }
> 
>  
> 
>> On Fri, Jan 29, 2016 at 1:48 PM, Amir Michail via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> On Jan 29, 2016, at 8:42 AM, Craig Cruden <ccruden at novafore.com> wrote:
>>> 
>>> still much worse.
>> 
>> What about: Bool(x?.isEmpty) // nil and false => false
>> 
>>> 
>>>>> On 2016-01-29, at 20:41:06, Amir Michail via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 
>>>>> On Jan 29, 2016, at 5:03 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>>>>> 
>>>>> I agree with Erica. The ?? operator is very readable IMO.
>>>>> 
>>>>> Furthermore x?(false).isEmpty looks like it would evaluate false.isEmpty when x is nil which is certainly not what is intended.
>>>> 
>>>> What about this then: ??(false, x?.isEmpty)
>>>> 
>>>>> In addition it would not be clear which default should be used in case of multiple optional chainings happening, i.e. what should be the result of person?(false).address?.(true).isEmpty
>>>>> 
>>>>> -Thorsten
>>>>> 
>>>>> 
>>>>>> Am 26. Januar 2016 um 03:29 schrieb Erica Sadun via swift-evolution <swift-evolution at swift.org>:
>>>>>> 
>>>>>> Not loving this. I'm quite happy with ??-coalescing and don't see
>>>>>> a compelling reason it needs to be "cleaner". I find your suggested
>>>>>> enhancement less readable. Looks like an optional chaining across 
>>>>>> a function.
>>>>>> 
>>>>>> -- E
>>>>>> 
>>>>>>> On Jan 25, 2016, at 7:03 PM, Amir Michail via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>> 
>>>>>>> Examples:
>>>>>>> 
>>>>>>> * instead of x ?? false, you would have x?(false)
>>>>>>> * instead of x?.isEmpty ?? false, you would have x?(false).isEmpty
>>>>>>> 
>>>>>>> I think this change would result in cleaner looking code.
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/0caf613b/attachment-0001.html>