This can actually be accomplished now using a closure:
let value = optionalValue ?? { throw CustomError.failure }()
However, this adds a layer of indirection that I’m not keen on and lacks the
readability and maintainability of a well-defined operator.
The problem with changing the nil-coalescing operator is that it means allowing
the second operand to be a statement rather than an expression, which I assume
would be seen as an unacceptable.
> On 9 Feb 2017, at 07:56, Brent Royal-Gordon <[email protected]> wrote:
>
>> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution
>> <[email protected]> wrote:
>>
>> I propose the introduction of a nil-rejection operator (represented here as
>> !!) as a complement to the above operators.
>> .
>> This operator should allow an equivalent behaviour to the forced unwrapping
>> of a variable, but with the provision of an error to throw in place of
>> throwing a fatal error.
>>
>> - value !! Error :
>> if value is nil, throw non-fatal error
>> if value is not nil, return value
>>
>> Example of how this syntax might work (Where CustomError: Error):
>>
>> let value = try optionalValue !! CustomError.failure
>
> Rather than invent a new operator, I'd prefer to make `throw` an expression
> rather than a statement. Then you could write:
>
> let value = optionalValue ?? throw CustomError.Failure
>
> One issue here would be figuring out the proper return type for `throw`.
> Although if `Never` were a subtype-of-all-types, that would of course work.
> :^)
>
> --
> Brent Royal-Gordon
> Architechies
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
