Two more tiny overloads is all takes to fix it:
func ??<T: Error>(lhs: T?, rhs: T) -> T {
if let lhs = lhs { return lhs } else { return rhs }
}
func ??<T: Error, U: Error>(lhs: T?, rhs: U) -> Error {
if let lhs = lhs { return lhs } else { return rhs }
}
> On Feb 9, 2017, at 12:01 PM, Jack Newcombe <[email protected]> wrote:
>
> While this is nice, it adds ambiguity to the nil-coalescing operator. For
> example, when using nil-coalescing with a wrapped error value and an
> unwrapped error value as operands:
>
> let optionalError: Errors? = nil
> let result = optionalError ?? Errors.generic
>
> The above will result in an "Ambiguous use of operator" error. Even if you
> were to somehow constrain the first argument to arguments of non-error types,
> it would still make the operator incongruous.
>
> On Thu, Feb 9, 2017 at 7:08 PM, Hooman Mehr <[email protected]
> <mailto:[email protected]>> wrote:
> I think the best solution is overloading the existing ?? operator. It is very
> easy to do:
>
> func ??<T,U: Error>(lhs: T?, rhs: U) throws -> T {
>
> if let lhs = lhs { return lhs } else { throw rhs }
> }
>
> then you can say:
>
> do {
>
> let y = try x ?? myError
>
> } catch ...
>
> It might even make sense to add to the standard library.
>
>> On Feb 9, 2017, at 12:04 AM, Jack Newcombe via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> 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]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution
>>>> <[email protected] <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
