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

[Amir Michail]

> On Jan 29, 2016, at 9:25 AM, Ross O'Brien <narrativium+swift at gmail.com> 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.
> 

How about this:

if? !x?.isEmpty { … } // if? nil { … } = if false { … }
while? !x?.isEmpty { … }
etc.

> "??(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 <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Jan 29, 2016, at 8:42 AM, Craig Cruden <ccruden at novafore.com <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Jan 29, 2016, at 5:03 AM, Thorsten Seitz <tseitz42 at icloud.com <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/80b0bab5/attachment.html>