[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Joe Groff jgroff at apple.com
Mon Feb 27 16:29:29 CST 2017


> On Feb 27, 2017, at 11:05 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
>> 
>>> On 24 Feb 2017, at 02:05, Ben Cohen wrote:
>>> 
>>> Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other Foundation types indicate a value-typed concrete type equivalent, which this won’t be. The recommendation is to use “Numeric" instead.
>> 
>> Does the `Error` protocol cause confusion with the `NSError` class?
>> 
>> I think `Number` is better than `Numeric`, because it is consistent with `SignedNumber`.
> 
> Error and NSError are actually related types, like String and NSString, and are used in roughly the same way. Numeric and NSNumber serve very different purposes: the former is a protocol for various operations, and the latter is a semi-type-erased class box around a *cough* numeric value that (deliberately) doesn't implement most of the operations in the protocol.

However, without doing anything, Numeric itself could serve the same type-erased box purpose. Since most arithmetic operations require `Self` arguments, they naturally wouldn't be available on the Numeric existential (unless someone designed and implemented an extension that handled up-conversion among arbitrary numeric types in the vein of Scheme's number tower or something like that). This seems like one place where that behavior would be desirable.

-Joe


More information about the swift-evolution mailing list