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

[Joe Groff via swift-evolution]

> On Feb 27, 2017, at 11:05 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

+1 to all of this.  I completely support the proposal now.

Thanks,
Jon

> On Feb 23, 2017, at 6:05 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> The core team met and reviewed the discussion of this proposal so far, and 
> had the following mid-review feedback to relay back to the list:
> 
> 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.
> Regarding the question of the trailing argument to distinguish 
> overflow-checking vs expanding versions of multiplied: rather than add an 
> enum or use the void trick in order to do this via arguments, it is better to 
> just distinguish the two functions via different base names.
> Regarding restoring the BitwiseOperations protocol – the team feels that the 
> bitset use case can be modeled with SetAlgebra rather than retaining a 
> protocol with only bitwise operators.
> popcount – although this is a term of art, in general it’s best to avoid 
> abbreviations, so the suggestion is to rename it populationCount, which also 
> helps settle whether the “c” should be capitalized and confusion over the 
> other meaning of “pop".
> 
> - Ben
> 
> 
>> On Feb 17, 2017, at 5:45 PM, Joe Groff via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
>> through February 25, 2017. This proposal was accepted for Swift 3, but was 
>> not implemented in time for the release. The revised proposal is available 
>> here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>  
>> 
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>>  Proposal link:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>  
>> 
>>  
>>  Reply text
>> 
>>  Other replies
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> Thank you,
>> 
>> -Joe Groff
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 25, 2017, at 8:28 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I assume that Number being renamed Numeric implies SignedNumber being renamed 
> SignedNumeric?
That is correct.

> On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>   
> >
> 
> > 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`.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
> 
>> 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.

Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

I assume that Number being renamed Numeric implies SignedNumber being
renamed SignedNumeric?
On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution <
swift-evolution@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`.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

> 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`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 24 Feb 2017, at 02:05, Ben Cohen via swift-evolution 
>  wrote:
> 
> Regarding the question of the trailing argument to distinguish 
> overflow-checking vs expanding versions of multiplied: rather than add an 
> enum or use the void trick in order to do this via arguments, it is better to 
> just distinguish the two functions via different base names.

Regarding trailing arguments, any chance we could get you to weigh in on on the 
"Allow trailing argument labels" discussion?
Personally I like the idea of using the trailing arguments, but not having to 
use enums to do it; a proper language feature could make it more viable. One 
variation discussion could for example looking like:

let result = a.adding(b):reportingOverflow

Think of the trailing "argument" as a kind of selector, telling Swift which 
specific version of the adding method you want to invoke. I prefer this to 
elongated method names, but maybe others wouldn't.

If there's appetite for that style though then it would make sense to implement 
the language feature first, rather than creating inconsistencies now.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 24, 2017, at 4:45 PM, Xiaodi Wu  wrote:
> 
> That was a deliberate design choice discussed during review of floating point 
> protocols. Floating point remainder and integer modulo are very different. 
> Spelling them the same way enables use in generic protocols, which would be 
> incorrect uses. This was borne out by observation of erroneous uses of 
> floating point % in Swift 2.
> On Fri, Feb 24, 2017 at 18:13 David Sweeris via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On Feb 23, 2017, at 14:44, David Sweeris  > wrote:
> 
>> 
>>> On Feb 23, 2017, at 2:33 PM, Karl Wagner >> > wrote:
>>> 
>>> 
 On 23 Feb 2017, at 19:40, Max Moiseev >>> > wrote:
 
 Conformance to Comparable is not required by anything in the standard 
 library. Besides, it is always possible to further constrain your own code 
 as in:
 
>>> 
>>> Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of 
>>> stuff, actually.
>>> 
 func f(_ x: T) where T.Magnitude : Comparable {}
 
 I would argue that adding constraints without solid proof of them being 
 useful and necessary is not the right thing to do.
 Also, sorting things by magnitude will require using a predicate-based 
 sorted() anyway, and that does not require Comparable.
 
 Max
>>> 
>>> Yes, but the constraints in the standard library should also convey some 
>>> meaning and be useful. What do we mean by a “magnitude” anyway? Won’t it be 
>>> strange in practice that I can create a “magnitude” out of nothing but an 
>>> arbitrary integer literal but can’t compare two values? Ultimately it looks 
>>> like a deficiency in the design to me - either it’s a simple scalar, 
>>> ExpressibleByIntegerLiteral and Comparable, or it’s something more complex 
>>> and can’t be either.
>>> 
>>> This is exactly the kind of flaw I’ve been working around with the current 
>>> Strideable.Stride (i.e. current SignedNumber). If a type is 
>>> ExpressibleByIntegerLiteral, you should be able to basically do all the 
>>> things to it that you can do with an integer.
>> 
>> (replying to bolded part)
>> 
>> Not necessarily... Complex numbers can conform to 
>> `ExpressibleByIntegerLiteral` but not `Comparable`. At least not in a 
>> generally-accepted way.
> 
> Perhaps a better example would be the `%` operator, since it involves stdlib 
> types. Floating point types are ExpressibleByIntegerLiteral, but don't have 
> the % operator that integers have.

Oh, I know. I was just pointing out another instance where a type conforms to 
`ExpressibleByIntegerLiteral` and can’t do something Int can do.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

That was a deliberate design choice discussed during review of floating
point protocols. Floating point remainder and integer modulo are very
different. Spelling them the same way enables use in generic protocols,
which would be incorrect uses. This was borne out by observation of
erroneous uses of floating point % in Swift 2.
On Fri, Feb 24, 2017 at 18:13 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 23, 2017, at 14:44, David Sweeris  wrote:
>
>
> On Feb 23, 2017, at 2:33 PM, Karl Wagner  wrote:
>
>
> On 23 Feb 2017, at 19:40, Max Moiseev  wrote:
>
> Conformance to Comparable is not required by anything in the standard
> library. Besides, it is always possible to further constrain your own code
> as in:
>
>
> Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of
> stuff, actually.
>
> func f(_ x: T) where T.Magnitude : Comparable {}
>
> I would argue that adding constraints without solid proof of them being
> useful and necessary is not the right thing to do.
> Also, sorting things by magnitude will require using a predicate-based
> sorted() anyway, and that does not require Comparable.
>
> Max
>
>
> Yes, but the constraints in the standard library should also convey some
> meaning and be useful. What do we mean by a “magnitude” anyway? Won’t it be
> strange in practice that I can create a “magnitude” out of nothing but an
> arbitrary integer literal but can’t compare two values? Ultimately it looks
> like a deficiency in the design to me - either it’s a simple scalar,
> ExpressibleByIntegerLiteral and Comparable, or it’s something more complex
> and can’t be either.
>
> This is exactly the kind of flaw I’ve been working around with the current
> Strideable.Stride (i.e. current SignedNumber). *If a type is
> ExpressibleByIntegerLiteral, you should be able to basically do all the
> things to it that you can do with an integer.*
>
>
> (replying to bolded part)
>
> Not necessarily... Complex numbers can conform to
> `ExpressibleByIntegerLiteral` but not `Comparable`. At least not in a
> generally-accepted way.
>
>
> Perhaps a better example would be the `%` operator, since it involves
> stdlib types. Floating point types are ExpressibleByIntegerLiteral, but
> don't have the % operator that integers have.
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 23, 2017, at 14:44, David Sweeris  wrote:
> 
> 
>>> On Feb 23, 2017, at 2:33 PM, Karl Wagner  wrote:
>>> 
>>> 
>>> On 23 Feb 2017, at 19:40, Max Moiseev  wrote:
>>> 
>>> Conformance to Comparable is not required by anything in the standard 
>>> library. Besides, it is always possible to further constrain your own code 
>>> as in:
>>> 
>> 
>> Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of 
>> stuff, actually.
>> 
>>> func f(_ x: T) where T.Magnitude : Comparable {}
>>> 
>>> I would argue that adding constraints without solid proof of them being 
>>> useful and necessary is not the right thing to do.
>>> Also, sorting things by magnitude will require using a predicate-based 
>>> sorted() anyway, and that does not require Comparable.
>>> 
>>> Max
>> 
>> Yes, but the constraints in the standard library should also convey some 
>> meaning and be useful. What do we mean by a “magnitude” anyway? Won’t it be 
>> strange in practice that I can create a “magnitude” out of nothing but an 
>> arbitrary integer literal but can’t compare two values? Ultimately it looks 
>> like a deficiency in the design to me - either it’s a simple scalar, 
>> ExpressibleByIntegerLiteral and Comparable, or it’s something more complex 
>> and can’t be either.
>> 
>> This is exactly the kind of flaw I’ve been working around with the current 
>> Strideable.Stride (i.e. current SignedNumber). If a type is 
>> ExpressibleByIntegerLiteral, you should be able to basically do all the 
>> things to it that you can do with an integer.
> 
> (replying to bolded part)
> 
> Not necessarily... Complex numbers can conform to 
> `ExpressibleByIntegerLiteral` but not `Comparable`. At least not in a 
> generally-accepted way.

Perhaps a better example would be the `%` operator, since it involves stdlib 
types. Floating point types are ExpressibleByIntegerLiteral, but don't have the 
% operator that integers have.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

Hi everyone,

The core team met and reviewed the discussion of this proposal so far, and had 
the following mid-review feedback to relay back to the list:

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.
Regarding the question of the trailing argument to distinguish 
overflow-checking vs expanding versions of multiplied: rather than add an enum 
or use the void trick in order to do this via arguments, it is better to just 
distinguish the two functions via different base names.
Regarding restoring the BitwiseOperations protocol – the team feels that the 
bitset use case can be modeled with SetAlgebra rather than retaining a protocol 
with only bitwise operators.
popcount – although this is a term of art, in general it’s best to avoid 
abbreviations, so the suggestion is to rename it populationCount, which also 
helps settle whether the “c” should be capitalized and confusion over the other 
meaning of “pop".

- Ben


> On Feb 17, 2017, at 5:45 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
> through February 25, 2017. This proposal was accepted for Swift 3, but was 
> not implemented in time for the release. The revised proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
>   Proposal link:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>   
>   Reply text
> 
>   Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Joe Groff
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 23, 2017, at 2:33 PM, Karl Wagner  wrote:
> 
> 
>> On 23 Feb 2017, at 19:40, Max Moiseev  wrote:
>> 
>> Conformance to Comparable is not required by anything in the standard 
>> library. Besides, it is always possible to further constrain your own code 
>> as in:
>> 
> 
> Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of stuff, 
> actually.
> 
>> func f(_ x: T) where T.Magnitude : Comparable {}
>> 
>> I would argue that adding constraints without solid proof of them being 
>> useful and necessary is not the right thing to do.
>> Also, sorting things by magnitude will require using a predicate-based 
>> sorted() anyway, and that does not require Comparable.
>> 
>> Max
> 
> Yes, but the constraints in the standard library should also convey some 
> meaning and be useful. What do we mean by a “magnitude” anyway? Won’t it be 
> strange in practice that I can create a “magnitude” out of nothing but an 
> arbitrary integer literal but can’t compare two values? Ultimately it looks 
> like a deficiency in the design to me - either it’s a simple scalar, 
> ExpressibleByIntegerLiteral and Comparable, or it’s something more complex 
> and can’t be either.
> 
> This is exactly the kind of flaw I’ve been working around with the current 
> Strideable.Stride (i.e. current SignedNumber). If a type is 
> ExpressibleByIntegerLiteral, you should be able to basically do all the 
> things to it that you can do with an integer.

(replying to bolded part)

Not necessarily... Complex numbers can conform to `ExpressibleByIntegerLiteral` 
but not `Comparable`. At least not in a generally-accepted way.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

Conformance to Comparable is not required by anything in the standard library. 
Besides, it is always possible to further constrain your own code as in:

func f(_ x: T) where T.Magnitude : Comparable {}

I would argue that adding constraints without solid proof of them being useful 
and necessary is not the right thing to do.
Also, sorting things by magnitude will require using a predicate-based sorted() 
anyway, and that does not require Comparable.

Max

> On Feb 23, 2017, at 9:59 AM, David Sweeris via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 23, 2017, at 9:54 AM, Karl Wagner > > wrote:
>> 
>> 
>>> On 23 Feb 2017, at 18:40, David Sweeris >> > wrote:
>>> 
>>> 
>>> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 
>> 
>> Are there Number types which can’t be Comparable?
>> 
>> Complex numbers. I believe `Number` is designed to allow a complex 
>> number type to conform.
>>  
 
 Magnitude could be comparable then. For vectors, matrices and complex 
 numbers, “magnitude” typically refers to a scalar. I don’t think we need 
 something broader than that.
>>> 
>>> Using magnitude for comparison leads to some decidedly odd places:
>>> let x: Complex = 1
>>> let y: Complex = -2
>>> x < y // returns true
>>> 
>>> - Dave Sweeris 
>> 
>> 
>> Fixed:
>>> let x: Complex = 1
>>> let y: Complex = -2
>>> x.magnitude < y.magnitude // returns true
>> 
>> I don’t mean we should compare all numbers by magnitude, only that the 
>> Magnitude associated type be required to be comparable. That way you could, 
>> for example, sort things by magnitude (if that’s useful to you).
>> 
>> Given that magnitudes appear to always be scalars (I couldn’t find an exact 
>> definition beyond a “norm”, which is a scalar), it seems fair to require 
>> them to be comparable.
> 
> Ah, ok, I misunderstood you. Yes, that seems reasonable to me.
> 
> - Dave Sweeris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Feb 23, 2017, at 10:40, Max Moiseev  wrote:
> 
> Conformance to Comparable is not required by anything in the standard library.

That surprises me. Isn't there a sort function or something, or did we change 
it so they all need a predicate now?

> I would argue that adding constraints without solid proof of them being 
> useful and necessary is not the right thing to do.
> Also, sorting things by magnitude will require using a predicate-based 
> sorted() anyway, and that does not require Comparable.

Yeah, if it's not needed... Well, it's easier to add it later if it turns out 
to be useful than to remove it if it gets in the way.

- Dave Sweeris 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 23, 2017, at 12:43 PM, David Sweeris  wrote:
> 
> 
> 
> 
> Sent from my iPhone
>> On Feb 23, 2017, at 10:40, Max Moiseev  wrote:
>> 
>> Conformance to Comparable is not required by anything in the standard 
>> library.
> 
> That surprises me. Isn't there a sort function or something, or did we change 
> it so they all need a predicate now?
I meant it’s not required from Number.Magnitude. Not in general.

> 
>> I would argue that adding constraints without solid proof of them being 
>> useful and necessary is not the right thing to do.
>> Also, sorting things by magnitude will require using a predicate-based 
>> sorted() anyway, and that does not require Comparable.
> 
> Yeah, if it's not needed... Well, it's easier to add it later if it turns out 
> to be useful than to remove it if it gets in the way.
> 
> - Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

> On 23 Feb 2017, at 19:40, Max Moiseev  wrote:
> 
> Conformance to Comparable is not required by anything in the standard 
> library. Besides, it is always possible to further constrain your own code as 
> in:
> 

Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of stuff, 
actually.

> func f(_ x: T) where T.Magnitude : Comparable {}
> 
> I would argue that adding constraints without solid proof of them being 
> useful and necessary is not the right thing to do.
> Also, sorting things by magnitude will require using a predicate-based 
> sorted() anyway, and that does not require Comparable.
> 
> Max

Yes, but the constraints in the standard library should also convey some 
meaning and be useful. What do we mean by a “magnitude” anyway? Won’t it be 
strange in practice that I can create a “magnitude” out of nothing but an 
arbitrary integer literal but can’t compare two values? Ultimately it looks 
like a deficiency in the design to me - either it’s a simple scalar, 
ExpressibleByIntegerLiteral and Comparable, or it’s something more complex and 
can’t be either.

This is exactly the kind of flaw I’ve been working around with the current 
Strideable.Stride (i.e. current SignedNumber). If a type is 
ExpressibleByIntegerLiteral, you should be able to basically do all the things 
to it that you can do with an integer.

- Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

Hi everyone,

The core team met and reviewed the discussion of this proposal so far, and had 
the following mid-review feedback to relay back to the list:

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.
Regarding the question of the trailing argument to distinguish 
overflow-checking vs expanding versions of multiplied: rather than add an enum 
or use the void trick in order to do this via arguments, it is better to just 
distinguish the two functions via different base names.
Regarding restoring the BitwiseOperations protocol – the team feels that the 
bitset use case can be modeled with SetAlgebra rather than retaining a protocol 
with only bitwise operators.
popcount – although this is a term of art, in general it’s best to avoid 
abbreviations, so the suggestion is to rename it populationCount, which also 
helps settle whether the “c” should be capitalized and confusion over the other 
meaning of “pop".

- Ben

> On Feb 17, 2017, at 5:45 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
> through February 25, 2017. This proposal was accepted for Swift 3, but was 
> not implemented in time for the release. The revised proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
>   Proposal link:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>   
>   Reply text
> 
>   Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Joe Groff
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 23, 2017, at 9:54 AM, Karl Wagner  wrote:
> 
> 
>> On 23 Feb 2017, at 18:40, David Sweeris > > wrote:
>> 
>> 
>> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
> 
> Are there Number types which can’t be Comparable?
> 
> Complex numbers. I believe `Number` is designed to allow a complex number 
> type to conform.
>  
>>> 
>>> Magnitude could be comparable then. For vectors, matrices and complex 
>>> numbers, “magnitude” typically refers to a scalar. I don’t think we need 
>>> something broader than that.
>> 
>> Using magnitude for comparison leads to some decidedly odd places:
>> let x: Complex = 1
>> let y: Complex = -2
>> x < y // returns true
>> 
>> - Dave Sweeris 
> 
> 
> Fixed:
>> let x: Complex = 1
>> let y: Complex = -2
>> x.magnitude < y.magnitude // returns true
> 
> I don’t mean we should compare all numbers by magnitude, only that the 
> Magnitude associated type be required to be comparable. That way you could, 
> for example, sort things by magnitude (if that’s useful to you).
> 
> Given that magnitudes appear to always be scalars (I couldn’t find an exact 
> definition beyond a “norm”, which is a scalar), it seems fair to require them 
> to be comparable.

Ah, ok, I misunderstood you. Yes, that seems reasonable to me.

- Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

> On 23 Feb 2017, at 18:40, David Sweeris  wrote:
> 
> 
> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
 
 Are there Number types which can’t be Comparable?
 
 Complex numbers. I believe `Number` is designed to allow a complex number 
 type to conform.
  
>> 
>> Magnitude could be comparable then. For vectors, matrices and complex 
>> numbers, “magnitude” typically refers to a scalar. I don’t think we need 
>> something broader than that.
> 
> Using magnitude for comparison leads to some decidedly odd places:
> let x: Complex = 1
> let y: Complex = -2
> x < y // returns true
> 
> - Dave Sweeris 


Fixed:
> let x: Complex = 1
> let y: Complex = -2
> x.magnitude < y.magnitude // returns true

I don’t mean we should compare all numbers by magnitude, only that the 
Magnitude associated type be required to be comparable. That way you could, for 
example, sort things by magnitude (if that’s useful to you).

Given that magnitudes appear to always be scalars (I couldn’t find an exact 
definition beyond a “norm”, which is a scalar), it seems fair to require them 
to be comparable.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[plx via swift-evolution]

> On Feb 23, 2017, at 11:31 AM, David Sweeris  wrote:
> 
> 
> On Feb 23, 2017, at 07:33, plx via swift-evolution  > wrote:
>> 
>> Next quibble: `Magnitude` being defined as the “absolute value” of the 
>> underlying type seems a bit nonsensical if e.g. `Number` is intended to be 
>> adoptable by complex numbers (let alone quaternions, matrices, and whatnot). 
>> What *would* a conforming complex # implementation be expected to return as 
>> e.g. `(1-i).magnitude`?
> 
> sqrt(2), I believe, or as close to it as can be represented by `Magnitude`

…which is what I’d expect if `x.magnitude` is supposed to be `||x||` or 
whatnot, but the stated motivation is:

  /// The magnitude of this value.
  ///
  /// For any numeric value `x`, `x.magnitude` is the absolute value of `x`.
  /// You can use the `magnitude` property in operations that are simpler to
  /// implement in terms of unsigned values, such as printing the value of an
  /// integer, which is just printing a '-' character in front of an absolute
  /// value.
  ///
  /// let x = -200
  /// // x.magnitude == 200

…for which uses the norm is not really helpful (and `Magnitude` not being 
`Comparable` is pretty annoying if it’s intended to be a norm; it really seems 
only intended to work as a generic tool for writing pretty-printers).

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
 
 Are there Number types which can’t be Comparable?
>>> 
>>> Complex numbers. I believe `Number` is designed to allow a complex number 
>>> type to conform.
>>>  
> 
> Magnitude could be comparable then. For vectors, matrices and complex 
> numbers, “magnitude” typically refers to a scalar. I don’t think we need 
> something broader than that.

Using magnitude for comparison leads to some decidedly odd places:
let x: Complex = 1
let y: Complex = -2
x < y // returns true

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 23, 2017, at 07:33, plx via swift-evolution 
>  wrote:
> 
> Next quibble: `Magnitude` being defined as the “absolute value” of the 
> underlying type seems a bit nonsensical if e.g. `Number` is intended to be 
> adoptable by complex numbers (let alone quaternions, matrices, and whatnot). 
> What *would* a conforming complex # implementation be expected to return as 
> e.g. `(1-i).magnitude`?

sqrt(2), I believe, or as close to it as can be represented by `Magnitude`. 
Speaking of which, in my own numerical code, `Magnitude` is typealiased to 
`Double` specifically because in complex numbers/quaternions/etc, it's almost 
guaranteed to never be reasonably approximated by an integer (at least for 
small numbers). What about having a "BuiltinScalar" protocol and setting it 
there, so that the non-scalar types that we write can define it as `Double` or 
some other appropriate real-valued type?

> PS: I suspect this ship has *long* sailed but I suspect that it would be 
> better in the long run to go the route of `Addable`, `Multipliable`, etc., 
> and use typealiases to define common groupings thereof; note that once you 
> remove `Magnitude`, the only difference between:
> 
> - `Number` (as defined)
> - `typealias Number = Equatable & ExpressibleByIntegerLiteral & Addable & 
> Multipliable`
> 
> …would be `init?(exactly source: T)`.

That's come up before, and IIRC, the decision was that it wasn't necessary for 
reasons that I no longer recall off the top of my head. Thanks for reminding me 
about it, though, as I've been meaning to go back and make sure that the 
reasoning still holds. (I'm sure it does, but part of the point of reviews is 
to have the community double-check the work to make sure we didn't miss 
anything, right?)

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[plx via swift-evolution]

+1 on most of it, with some minor quibbles.

First quibble: between `Number` and `Arithmetic` I’d prefer `Arithmetic`; this 
is 50/50 aesthetics and concern about clarity vis-a-vis `(NS)Number`, 
`(NS)DecimalNumber`, and so on.

Next quibble: `Magnitude` being defined as the “absolute value” of the 
underlying type seems a bit nonsensical if e.g. `Number` is intended to be 
adoptable by complex numbers (let alone quaternions, matrices, and whatnot). 
What *would* a conforming complex # implementation be expected to return as 
e.g. `(1-i).magnitude`? For the intended use this seems like it needs to be 
moved out of the basic `Number`/`Arithmetic` protocol into a new protocol.

Final quibble: is there an official stance as to whether or not 
`Number/`Arithmetic` is allowed to have non-commutative multiplication? I see 
would prefer any policy on this be explicitly documented.

If `Number`/`Arithmetic` *is* intended to allow adopters with non-commutative 
multiplication, then it’s seemingly missing an overridable method:

- this exists: `x *= y` (presumably equivalent to `x = x * y`)
- this doesn't: `x =* y` (presumably equivalent to one of `x = y * x` *or* `y = 
x * y`, your preference)

…(alternative operator names are fine, the important bit is an in-place 
multiplication-from-the-left). Not necessary, but still nice to have for 
non-commutative adoptees.

PS: I suspect this ship has *long* sailed but I suspect that it would be better 
in the long run to go the route of `Addable`, `Multipliable`, etc., and use 
typealiases to define common groupings thereof; note that once you remove 
`Magnitude`, the only difference between:

- `Number` (as defined)
- `typealias Number = Equatable & ExpressibleByIntegerLiteral & Addable & 
Multipliable`

…would be `init?(exactly source: T)`.

Although this is an extra method and thus extra “semantics”, I think there’s a 
perfectly-reasonable argument that—at least informally—the *semantics* of 
`init?(exactly source: T)` are already-implied by the 
adoption of `ExpressibleByIntegerLiteral`; in fact, are there any types that 
*could* reasonably adopt `ExpressibleByIntegerLiteral` but *could not* 
reasonably implement `init?(exactly source: T)`? 

Anyways, that’s my 2c on this: the Integer-related aspects seem fine, but I 
have quibbles vis-a-vis the foundational protocol.

> On Feb 17, 2017, at 7:45 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
> through February 25, 2017. This proposal was accepted for Swift 3, but was 
> not implemented in time for the release. The revised proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
>   Proposal link:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>   
>   Reply text
> 
>   Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Joe Groff
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

>> 
>> Are there Number types which can’t be Comparable?
>> 
>> Complex numbers. I believe `Number` is designed to allow a complex number 
>> type to conform.
>>  

Magnitude could be comparable then. For vectors, matrices and complex numbers, 
“magnitude” typically refers to a scalar. I don’t think we need something 
broader than that.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 22, 2017, at 10:55 AM, Max Moiseev via swift-evolution 
>  wrote:
> 
>> default func multiplied(by other: Self) -> Self // `default` means try 
>> resolving ambiguities with this version first. The overloaded versions are 
>> only considered if the type-checker can’t make this version work.
> 
> This feature is not strictly required in this case, as we moved away from 
> using `multiplied` of type (Self, Self) -> Self to using proper `static func 
> +`. So the ambiguity will *not* happen in the most common case when you want 
> to multiply two numbers of some type and get the result of the same type. 
> Ambiguity will only become a problem in what I believe to be a very less 
> frequent case, when you want to do something very special, like, catch the 
> overflow explicitly or get the full result in a form of DoubleWidth.

True, but I think the only reason we're not using operators for the other 
`multiplied` variants is that they need the third parameter. So we could 
instead specify:

default static func * (lhs: Self, rhs: Self) -> Self
static func * (lhs: Self, rhs: Self) -> (partialValue: Self, overflow: 
ArithmeticOverflow)
static func * (lhs: Self, rhs: Self) -> DoubleWidth

And not have to worry about these names at all.

(On the other hand, the reversed DoubleWidth division would still be a problem. 
But isn't there a proposal in the works to add `\` to the operator characters?)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 22, 2017, at 8:47 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> There is another option to avoid the extra types, which is to stop trying to 
>> force the disambiguation through argument labels, accept an ambiguous call 
>> and have the context disambiguate:
>> 
>> // compilation error: ambiguous
>> let x = i.multiplied(by: j)
>> // unambiguously overflow-checked
>> let (y,overflow) = i.multiplied(by: j)
>> // unambiguously full-width
>> let z: DoubleWidth = i.multiplied(by: j)
>> 
>> Ambiguity is bad when you want to distinguish between the “usual one” versus 
>> other more specialized versions. So if you really had a regular trapping 
>> `adding`, but then also wanted to accommodate the overflow-reporting version 
>> when a user explicitly requests it, then the argument label is a clear win. 
>> This is a slightly bogus example though, because we explicitly don’t have 
>> things like `adding`, we have a `static +` instead. Where the disambiguation 
>> is needed is instead between two less common variants as described above.
> 
> It’d need a new language feature to support it, but what having “default” 
> resolutions for overloaded functions?
> default func multiplied(by other: Self) -> Self // `default` means try 
> resolving ambiguities with this version first. The overloaded versions are 
> only considered if the type-checker can’t make this version work.

This feature is not strictly required in this case, as we moved away from using 
`multiplied` of type (Self, Self) -> Self to using proper `static func +`. So 
the ambiguity will *not* happen in the most common case when you want to 
multiply two numbers of some type and get the result of the same type. 
Ambiguity will only become a problem in what I believe to be a very less 
frequent case, when you want to do something very special, like, catch the 
overflow explicitly or get the full result in a form of DoubleWidth.

> func multiplied(by other: Self) -> (partialValue: Self, overflow: 
> ArithmeticOverflow)
> func multiplied(by other: Self) -> DoubleWidth
> 
> // signature matches default implementation, use that 
> let x = i.multiplied(by: j)
> // default version doesn’t return a tuple, so try the overloads… matches the 
> overflow-checked function
> let (y,overflow) = i.multiplied(by: j)
> // default version doesn’t return a DoubleWidth, so try the overloads… 
> matches the double-width function
> let z: DoubleWidth = i.multiplied(by: j)
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
> There is another option to avoid the extra types, which is to stop trying to 
> force the disambiguation through argument labels, accept an ambiguous call 
> and have the context disambiguate:
> 
> // compilation error: ambiguous
> let x = i.multiplied(by: j)
> // unambiguously overflow-checked
> let (y,overflow) = i.multiplied(by: j)
> // unambiguously full-width
> let z: DoubleWidth = i.multiplied(by: j)
> 
> Ambiguity is bad when you want to distinguish between the “usual one” versus 
> other more specialized versions. So if you really had a regular trapping 
> `adding`, but then also wanted to accommodate the overflow-reporting version 
> when a user explicitly requests it, then the argument label is a clear win. 
> This is a slightly bogus example though, because we explicitly don’t have 
> things like `adding`, we have a `static +` instead. Where the disambiguation 
> is needed is instead between two less common variants as described above.

It’d need a new language feature to support it, but what having “default” 
resolutions for overloaded functions?
default func multiplied(by other: Self) -> Self // `default` means try 
resolving ambiguities with this version first. The overloaded versions are only 
considered if the type-checker can’t make this version work.
func multiplied(by other: Self) -> (partialValue: Self, overflow: 
ArithmeticOverflow)
func multiplied(by other: Self) -> DoubleWidth

// signature matches default implementation, use that 
let x = i.multiplied(by: j)
// default version doesn’t return a tuple, so try the overloads… matches the 
overflow-checked function
let (y,overflow) = i.multiplied(by: j)
// default version doesn’t return a DoubleWidth, so try the overloads… matches 
the double-width function
let z: DoubleWidth = i.multiplied(by: j)

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

There is another option to avoid the extra types, which is to stop trying to 
force the disambiguation through argument labels, accept an ambiguous call and 
have the context disambiguate:

// compilation error: ambiguous
let x = i.multiplied(by: j)
// unambiguously overflow-checked
let (y,overflow) = i.multiplied(by: j)
// unambiguously full-width
let z: DoubleWidth = i.multiplied(by: j)

Ambiguity is bad when you want to distinguish between the “usual one” versus 
other more specialized versions. So if you really had a regular trapping 
`adding`, but then also wanted to accommodate the overflow-reporting version 
when a user explicitly requests it, then the argument label is a clear win. 
This is a slightly bogus example though, because we explicitly don’t have 
things like `adding`, we have a `static +` instead. Where the disambiguation is 
needed is instead between two less common variants as described above.


> On Feb 21, 2017, at 11:51 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> For the review, Dave asked me to raise a design question on his behalf, since 
> he's on vacation. There are places where the proposal introduces one-case 
> types as a labeling mechanism to distinguish different operations with 
> otherwise the same argument names, for instance:
> 
> public enum ReportingOverflow { case reportingOverflow }
> 
> protocol Number {
>  func adding(_ other: Self) -> Self
> }
> 
> protocol FixedWidthInteger: BinaryInteger {
>  func adding(_ other: Self, _: ReportingOverflow) -> (partialValue: Self, 
> overflow: ArithmeticOverflow)
> }
> 
> This introduces an otherwise useless type (for which we need to emit 
> metadata, provide documentation for, list in reference documentation and code 
> completion, etc.) and turns the compiler's job of choosing among these 
> operators into an overload resolution problem rather than a simpler name 
> lookup problem. In other places, particularly when a type imported from Cocoa 
> has multiple nullary initializers, we already use the convention of a 
> Void-typed labeled argument, which would look like this:
> 
> protocol FixedWidthInteger: BinaryInteger {
>  func adding(_ other: Self, reportingOverflow: Void) -> (partialValue: Self, 
> overflow: ArithmeticOverflow)
> }
> 
> The call syntax is less aethestically pleasing, no doubt (`adding(5, 
> reportingOverflow: ())`), but that's arguably a problem we should address at 
> the language level given that we already have APIs that look like that. The 
> tradeoff of ugly syntax, which we can potentially beautify over time, in 
> return for less "stuff" in the standard library, which we can't get rid off 
> once the dylib is burned into billions of user devices, is worth considering.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 21, 2017, at 2:04 PM, Karl Wagner  wrote:
> 
> 
>> On 21 Feb 2017, at 21:39, Max Moiseev > > wrote:
>> 
>> 
>>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I assume the “SignedNumber” protocol is the same as the existing one in the 
>>> standard library. That is to say, Strideable.Stride will now conform to 
>>> Number and have operators.
>> SignedNumber will *not* be the same. It is just the same name.
>> Stride will have operators, yes. Strideable in general will not, unless it’s 
>> a _Pointer. (you can find the current implementation prototype here 
>> ).
> 
> Currently, it’s difficult to work with Strideable because you can calculate 
> distances between them (as type Strideable.Stride), but you can’t add those 
> distances because Strideable.Stride is only constrained to conform to 
> “SignedNumber”, which is a pretty useless protocol.
> 
> In the prototype, Strideable.Stride has now been changed, so it is 
> constrained to “SignedArithmetic” (which, apparently, is to be renamed 
> “SignedNumber”). So essentially, the existing SignedNumber has been 
> re-parented to “Number” and gains operations such as addition. That’s great!
Ah.. I see what you mean. Thanks for the explanation. I think we usually just 
used Bound : Strideable, Bound.Stride : SignedInteger, but yes, you’re right, 
it will be simpler now.

> I think it would be worth including Strideable in the “big picture” in the 
> proposal/manifesto, showing how it fits in..
That can be a valuable addition, indeed. Thanks!

> 
>>> 
>>> Also minor nitpick, would it be too onerous to require Number.Magnitude to 
>>> be Comparable? Currently it’s only Equatable and 
>>> ExpressibleByIntegerLiteral.
>> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it 
>> ends up being called), but the recursive constraints feature is missing, 
>> therefore we constrained it with the protocols that Arithmetic itself 
>> refines.
>> 
>> Why would you want Comparable?
>> 
>> Max
>> 
> 
> I suppose that leads me on to the question of why Number itself only requires 
> that conformers be (Equatable & ExpressibleByIntegerLiteral) and does not 
> require that they be Comparable.
> 
> If I must be able to create any “Number" out of thin air with an integer 
> literal, is it not reasonable to also require that I am able to compare two 
> instances?
> 
> Are there Number types which can’t be Comparable?


> 
> - Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 4:04 PM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 21 Feb 2017, at 21:39, Max Moiseev  wrote:
>
>
> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I assume the “SignedNumber” protocol is the same as the existing one in
> the standard library. That is to say, Strideable.Stride will now conform to
> Number and have operators.
>
> SignedNumber will *not* be the same. It is just the same name.
> Stride will have operators, yes. Strideable in general will not, unless
> it’s a _Pointer. (you can find the current implementation prototype here
> 
> ).
>
>
> Currently, it’s difficult to work with Strideable because you can
> calculate distances between them (as type Strideable.Stride), but you can’t
> add those distances because Strideable.Stride is only constrained to
> conform to “SignedNumber”, which is a pretty useless protocol.
>
> In the prototype, Strideable.Stride has now been changed, so it is
> constrained to “SignedArithmetic” (which, apparently, is to be renamed
> “SignedNumber”). So essentially, the existing SignedNumber has been
> re-parented to “Number” and gains operations such as addition. That’s great!
>
> I think it would be worth including Strideable in the “big picture” in the
> proposal/manifesto, showing how it fits in..
>
>
> Also minor nitpick, would it be too onerous to require Number.Magnitude to
> be Comparable? Currently it’s only Equatable and
> ExpressibleByIntegerLiteral.
>
> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it
> ends up being called), but the recursive constraints feature is missing,
> therefore we constrained it with the protocols that Arithmetic itself
> refines.
>
> Why would you want Comparable?
>
> Max
>
>
> I suppose that leads me on to the question of why Number itself only
> requires that conformers be (Equatable & ExpressibleByIntegerLiteral) and
> does not require that they be Comparable.
>
> If I must be able to create any “Number" out of thin air with an integer
> literal, is it not reasonable to also require that I am able to compare two
> instances?
>
> Are there Number types which can’t be Comparable?
>

Complex numbers. I believe `Number` is designed to allow a complex number
type to conform.


>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

> On 21 Feb 2017, at 21:39, Max Moiseev  wrote:
> 
> 
>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I assume the “SignedNumber” protocol is the same as the existing one in the 
>> standard library. That is to say, Strideable.Stride will now conform to 
>> Number and have operators.
> SignedNumber will *not* be the same. It is just the same name.
> Stride will have operators, yes. Strideable in general will not, unless it’s 
> a _Pointer. (you can find the current implementation prototype here 
> ).

Currently, it’s difficult to work with Strideable because you can calculate 
distances between them (as type Strideable.Stride), but you can’t add those 
distances because Strideable.Stride is only constrained to conform to 
“SignedNumber”, which is a pretty useless protocol.

In the prototype, Strideable.Stride has now been changed, so it is constrained 
to “SignedArithmetic” (which, apparently, is to be renamed “SignedNumber”). So 
essentially, the existing SignedNumber has been re-parented to “Number” and 
gains operations such as addition. That’s great!

I think it would be worth including Strideable in the “big picture” in the 
proposal/manifesto, showing how it fits in..

>> 
>> Also minor nitpick, would it be too onerous to require Number.Magnitude to 
>> be Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.
> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it 
> ends up being called), but the recursive constraints feature is missing, 
> therefore we constrained it with the protocols that Arithmetic itself refines.
> 
> Why would you want Comparable?
> 
> Max
> 

I suppose that leads me on to the question of why Number itself only requires 
that conformers be (Equatable & ExpressibleByIntegerLiteral) and does not 
require that they be Comparable.

If I must be able to create any “Number" out of thin air with an integer 
literal, is it not reasonable to also require that I am able to compare two 
instances?

Are there Number types which can’t be Comparable?

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 1:51 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> For the review, Dave asked me to raise a design question on his behalf,
> since he's on vacation. There are places where the proposal introduces
> one-case types as a labeling mechanism to distinguish different operations
> with otherwise the same argument names, for instance:
>
> public enum ReportingOverflow { case reportingOverflow }
>
> protocol Number {
>   func adding(_ other: Self) -> Self
> }
>
> protocol FixedWidthInteger: BinaryInteger {
>   func adding(_ other: Self, _: ReportingOverflow) -> (partialValue: Self,
> overflow: ArithmeticOverflow)
> }
>
> This introduces an otherwise useless type (for which we need to emit
> metadata, provide documentation for, list in reference documentation and
> code completion, etc.) and turns the compiler's job of choosing among these
> operators into an overload resolution problem rather than a simpler name
> lookup problem. In other places, particularly when a type imported from
> Cocoa has multiple nullary initializers, we already use the convention of a
> Void-typed labeled argument, which would look like this:
>
> protocol FixedWidthInteger: BinaryInteger {
>   func adding(_ other: Self, reportingOverflow: Void) -> (partialValue:
> Self, overflow: ArithmeticOverflow)
> }
>
> The call syntax is less aethestically pleasing, no doubt (`adding(5,
> reportingOverflow: ())`), but that's arguably a problem we should address
> at the language level given that we already have APIs that look like that.
> The tradeoff of ugly syntax, which we can potentially beautify over time,
> in return for less "stuff" in the standard library, which we can't get rid
> off once the dylib is burned into billions of user devices, is worth
> considering.
>

+1. That seems like the wiser (if less "clever") solution.

>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 3:27 PM, Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel 
> wrote:
>
> I've followed this for a long time and work a lot with number/big num
> related code, and I must say I'm really excited about the way this is
> turning out!
>
> *Popcount & leadingZeroBits*
> - *Placement:* What's the rationale behind placing popcount & clz on
> fixed width integer instead of BinaryInteger? It seems implementing these
> would be trivial also for BigInt types.
>
> Arbitrary sized signed -1 can have different popcount depending on the
> underlying buffer length (if there is a buffer) even if it’s the same type
> and the same value. Same with leading zeros, as the underlying
> representation is unbounded on the more significant side.
>
> - *Naming: W*hy does popcount retain the term of art? Considering it's
> relatively obscure it would seem numberOfOneBits or something along those
> lines would be a more consistent choice.
>
> The thinking was something like: people who know it, know it by this name
> and will be a little annoyed, people who don’t know what it is, and simply
> want their stack overflow snippet to work, will not be able to identify it
> under any other name. So a non-term-of-art name would not really benefit
> anyone, other than our naming guidelines.
>
> Also, arguably shouldn't it be numberOfLeadingZeroBits?
>
> There is countLeadingZeroBits for that.
>
> I'm very happy with the inclusion of exposing these instructions btw, I've
> run into them lacking more than once before!
>
> What would you say about popcount being a protocol requirement? If you’ve
> needed it, was it in the generic context or on concrete types?
>

So I for one have needed it. The question Jordan asked was interesting,
because on reflection I've only needed it so far on concrete types. That
said, in part that must be chalked up to integer generics not being really
usable in the past.

On balance, MHO is that it's worthwhile to make it a protocol requirement
(defaulted of course). It makes sense that all fixed-width integers have a
popcount (and leadingZeroBits), just as they all have a bitWidth. Now, some
fixed-width integers might not have a very optimized way of computing that
popcount, but still. It is not out of the question that one would want to
do some work based on the bits in a generic integer that has a fixed number
of bits.

*FullWidth & ReportingOverflow*
> That's pretty clever there with the trailing argument :). Do you know
> whether there is any technical reason why we couldn't support a trailing
> 'argument label' without actual argument directly in the language? If not I
> might want to write up a proposal for that because if run into wanting this
> for a longer time. E.g. delegate methods would be a very common case:
> tableView(_:numberOfSections) is a lot more consistent with all other
> delegate methods.
>
> Joe recently sent an email on behalf of Dave to start this very discussion.
>
>
> *Division on Number?*
> The intro of the proposal puts division under Number, while the detailed
> design puts it under BinaryInteger, which is it?
>
> It is one of the most recent changes, division is *not* in the Number. It
> was moved down the hierarchy to BinaryInteger. I’ll fix the proposal.
> Thanks!
>
> Max
>
>
> On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I assume the “SignedNumber” protocol is the same as the existing one in
>> the standard library. That is to say, Strideable.Stride will now conform to
>> Number and have operators.
>>
>> SignedNumber will *not* be the same. It is just the same name.
>> Stride will have operators, yes. Strideable in general will not, unless
>> it’s a _Pointer. (you can find the current implementation prototype here
>> 
>> ).
>>
>>
>> Also minor nitpick, would it be too onerous to require Number.Magnitude
>> to be Comparable? Currently it’s only Equatable and
>> ExpressibleByIntegerLiteral.
>>
>> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it
>> ends up being called), but the recursive constraints feature is missing,
>> therefore we constrained it with the protocols that Arithmetic itself
>> refines.
>>
>> Why would you want Comparable?
>>
>> Max
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
http

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

[Max Moiseev via swift-evolution]

> On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel  
> wrote:
> 
> I've followed this for a long time and work a lot with number/big num related 
> code, and I must say I'm really excited about the way this is turning out!
> 
> Popcount & leadingZeroBits
> - Placement: What's the rationale behind placing popcount & clz on fixed 
> width integer instead of BinaryInteger? It seems implementing these would be 
> trivial also for BigInt types.
Arbitrary sized signed -1 can have different popcount depending on the 
underlying buffer length (if there is a buffer) even if it’s the same type and 
the same value. Same with leading zeros, as the underlying representation is 
unbounded on the more significant side.

> - Naming: Why does popcount retain the term of art? Considering it's 
> relatively obscure it would seem numberOfOneBits or something along those 
> lines would be a more consistent choice.
The thinking was something like: people who know it, know it by this name and 
will be a little annoyed, people who don’t know what it is, and simply want 
their stack overflow snippet to work, will not be able to identify it under any 
other name. So a non-term-of-art name would not really benefit anyone, other 
than our naming guidelines.

> Also, arguably shouldn't it be numberOfLeadingZeroBits?
There is countLeadingZeroBits for that.

> I'm very happy with the inclusion of exposing these instructions btw, I've 
> run into them lacking more than once before!
What would you say about popcount being a protocol requirement? If you’ve 
needed it, was it in the generic context or on concrete types?
> 
> FullWidth & ReportingOverflow
> That's pretty clever there with the trailing argument :). Do you know whether 
> there is any technical reason why we couldn't support a trailing 'argument 
> label' without actual argument directly in the language? If not I might want 
> to write up a proposal for that because if run into wanting this for a longer 
> time. E.g. delegate methods would be a very common case: 
> tableView(_:numberOfSections) is a lot more consistent with all other 
> delegate methods.
Joe recently sent an email on behalf of Dave to start this very discussion.

> 
> Division on Number?
> The intro of the proposal puts division under Number, while the detailed 
> design puts it under BinaryInteger, which is it?
It is one of the most recent changes, division is *not* in the Number. It was 
moved down the hierarchy to BinaryInteger. I’ll fix the proposal. Thanks!

Max

> 
> On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I assume the “SignedNumber” protocol is the same as the existing one in the 
>> standard library. That is to say, Strideable.Stride will now conform to 
>> Number and have operators.
> SignedNumber will *not* be the same. It is just the same name.
> Stride will have operators, yes. Strideable in general will not, unless it’s 
> a _Pointer. (you can find the current implementation prototype here 
> ).
>> 
>> Also minor nitpick, would it be too onerous to require Number.Magnitude to 
>> be Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.
> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it 
> ends up being called), but the recursive constraints feature is missing, 
> therefore we constrained it with the protocols that Arithmetic itself refines.
> 
> Why would you want Comparable?
> 
> Max
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Patrick Pijnappel via swift-evolution]

I've followed this for a long time and work a lot with number/big num
related code, and I must say I'm really excited about the way this is
turning out!

*Popcount & leadingZeroBits*
- *Placement:* What's the rationale behind placing popcount & clz on fixed
width integer instead of BinaryInteger? It seems implementing these would
be trivial also for BigInt types.
- *Naming: W*hy does popcount retain the term of art? Considering it's
relatively obscure it would seem numberOfOneBits or something along those
lines would be a more consistent choice. Also, arguably shouldn't it be
numberOfLeadingZeroBits?
I'm very happy with the inclusion of exposing these instructions btw, I've
run into them lacking more than once before!

*FullWidth & ReportingOverflow*
That's pretty clever there with the trailing argument :). Do you know
whether there is any technical reason why we couldn't support a trailing
'argument label' without actual argument directly in the language? If not I
might want to write up a proposal for that because if run into wanting this
for a longer time. E.g. delegate methods would be a very common case:
tableView(_:numberOfSections) is a lot more consistent with all other
delegate methods.

*Division on Number?*
The intro of the proposal puts division under Number, while the detailed
design puts it under BinaryInteger, which is it?

On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I assume the “SignedNumber” protocol is the same as the existing one in
> the standard library. That is to say, Strideable.Stride will now conform to
> Number and have operators.
>
> SignedNumber will *not* be the same. It is just the same name.
> Stride will have operators, yes. Strideable in general will not, unless
> it’s a _Pointer. (you can find the current implementation prototype here
> 
> ).
>
>
> Also minor nitpick, would it be too onerous to require Number.Magnitude to
> be Comparable? Currently it’s only Equatable and
> ExpressibleByIntegerLiteral.
>
> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it
> ends up being called), but the recursive constraints feature is missing,
> therefore we constrained it with the protocols that Arithmetic itself
> refines.
>
> Why would you want Comparable?
>
> Max
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> I assume the “SignedNumber” protocol is the same as the existing one in the 
> standard library. That is to say, Strideable.Stride will now conform to 
> Number and have operators.
SignedNumber will *not* be the same. It is just the same name.
Stride will have operators, yes. Strideable in general will not, unless it’s a 
_Pointer. (you can find the current implementation prototype here 
).
> 
> Also minor nitpick, would it be too onerous to require Number.Magnitude to be 
> Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.
Magnitude is supposed to conform to Arithmetic (or Number, or whatever it ends 
up being called), but the recursive constraints feature is missing, therefore 
we constrained it with the protocols that Arithmetic itself refines.

Why would you want Comparable?

Max

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 17, 2017, at 7:41 PM, Hugo Hennies via swift-evolution 
>  wrote:
> 
> I would argue against the deprecation of the BitwiseOperations protocol 
> though. I believe a bitset type would be a good candidate for conformance to 
> this protocol while at the same time not being an integer at all. 

Wouldn’t SetAlgebra be a better protocol for a bitset?

Max 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

For the review, Dave asked me to raise a design question on his behalf, since 
he's on vacation. There are places where the proposal introduces one-case types 
as a labeling mechanism to distinguish different operations with otherwise the 
same argument names, for instance:

public enum ReportingOverflow { case reportingOverflow }

protocol Number {
  func adding(_ other: Self) -> Self
}

protocol FixedWidthInteger: BinaryInteger {
  func adding(_ other: Self, _: ReportingOverflow) -> (partialValue: Self, 
overflow: ArithmeticOverflow)
}

This introduces an otherwise useless type (for which we need to emit metadata, 
provide documentation for, list in reference documentation and code completion, 
etc.) and turns the compiler's job of choosing among these operators into an 
overload resolution problem rather than a simpler name lookup problem. In other 
places, particularly when a type imported from Cocoa has multiple nullary 
initializers, we already use the convention of a Void-typed labeled argument, 
which would look like this:

protocol FixedWidthInteger: BinaryInteger {
  func adding(_ other: Self, reportingOverflow: Void) -> (partialValue: Self, 
overflow: ArithmeticOverflow)
}

The call syntax is less aethestically pleasing, no doubt (`adding(5, 
reportingOverflow: ())`), but that's arguably a problem we should address at 
the language level given that we already have APIs that look like that. The 
tradeoff of ugly syntax, which we can potentially beautify over time, in return 
for less "stuff" in the standard library, which we can't get rid off once the 
dylib is burned into billions of user devices, is worth considering.

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

On Fri, Feb 17, 2017, at 08:45 PM, Joe Groff via swift-evolution wrote:
> • What is your evaluation of the proposal?



Extremely strong +1.



Unlike others, I agree with the proposed deprecation of
BitwiseOperations. It's not pulling its own weight under this new model.
I encourage other reviewers to try, as the proposal suggests, to come up
with a compelling user of just BitwiseOperations.


> • Is the problem being addressed significant enough to warrant a
> change to Swift?


Yes; it's not as easy to work with integers in Swift 3 as floating
point, which is annoying, since integers are important to binary
programming.


> • Does this proposal fit well with the feel and direction of Swift?



The graph of methods and protocols is well-considered, and while it's
probably not mathematically perfect, I could easily see the API being
used to teach binary arithmetic.


> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?


I've tried (and failed) to use Swift's previous protocols for generic
programming.


> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?


Thorough reading of previous revisions, glance through of this one.
Thanks for providing the updates section!


Sincerely,

  Zachary Waldowski

  z...@waldowski.me




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

>   • What is your evaluation of the proposal?

+1

I assume the “SignedNumber” protocol is the same as the existing one in the 
standard library. That is to say, Strideable.Stride will now conform to Number 
and have operators.

Also minor nitpick, would it be too onerous to require Number.Magnitude to be 
Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Sure is

>   • Does this proposal fit well with the feel and direction of Swift?

Yup

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Nope

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed previous discussions, read proposal twice.

- Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 
>   • What is your evaluation of the proposal?

+1.  Very nice!


>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Very much so.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Unfortunately, no.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick read this time.  I read prior versions in depth.

> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Joe Groff
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 01:45, Joe Groff via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?

Solid +1, though like others I disagree with deprecating BitwiseOperations, and 
feel it should be integrated into the protocol hierarchy.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Definitely; interpretability of integers and some ambiguity with the types are 
weaknesses in Swift right now, so the improved design should make a big 
difference.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've been keeping an eye on the discussion and skimmed the proposal again to 
hopefully catch any changes.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Hugo Hennies via swift-evolution]

> • What is your evaluation of the proposal?

Very good. It's a much needed improvement to the language's integer protocols 
and type hierarchy.

I would argue against the deprecation of the BitwiseOperations protocol though. 
I believe a bitset type would be a good candidate for conformance to this 
protocol while at the same time not being an integer at all. 

I do not propose to a standard library implementation of a bitset type, but I 
think the standard protocols should let themselves to be easily extended and 
implemented by user types. Assuming only integers will ever have bitwise 
operations might limit users and force them to write duplicate code.

> • Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes, the previous protocols were confusing and didn't let themselves very well 
to generic programming over the various integer types of the language.

> • Does this proposal fit well with the feel and direction of Swift?

Yes, this proposal very much captures the feel of the language and it's 
standard library.

> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?

I haven't used a language before that I could compare effectively with the 
features proposed here.

> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

A quick reading.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

> • What is your evaluation of the proposal?
>

Excellent, even better than the first take. Still not sure about the
`FullWidth` design, but it'll do.

• Is the problem being addressed significant enough to warrant a change to
> Swift?
>

Yes, the previous protocols were confusing and ultimately not very useful.

• Does this proposal fit well with the feel and direction of Swift?
>

Yes, after overhauling floating point protocols, the rest of the numeric
types are overdue for this change.

• If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?
>

I've struggled with the Swift 2/3 integer protocols, does that count? This
proposal is a huge improvement.

• How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>

In-depth study.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

Hello Swift community,

The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
through February 25, 2017. This proposal was accepted for Swift 3, but was not 
implemented in time for the release. The revised proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

Reply text

Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change 
to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe Groff
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution