undefined

Evolution Discussion
1

It seems IntegerArithmeticType should have a conversion from IntMax, in
analogy with Signed/UnsignedIntegerType. It already has toIntMax(), but not
the reverse conversion. This is important to be able to write generic
algorithms on IntegerArithmeticType. Are there any reasons it shouldn't?

2

https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb

HTH,

···

on Thu Jan 28 2016, James Campbell <swift-evolution@swift.org> wrote:

I think there is some sort of documentation or work being done on Number
Types in Swift to make it a more robust solution rather than the bunch of
lop-sided classes we have right now.

--
-Dave

3

I agree, I think this would require all integer types to have mandatory init(_:IntMax), init(_:UIntMax), init(truncatingBitPattern:IntMax) and init(truncatingBitPattern:UIntMax) constructors? Would make working with arbitrary sized integers in a generic way a lot easier.

···

On 28 Jan 2016, at 04:02, Patrick Pijnappel via swift-evolution <swift-evolution@swift.org> wrote:

It seems IntegerArithmeticType should have a conversion from IntMax, in analogy with Signed/UnsignedIntegerType. It already has toIntMax(), but not the reverse conversion. This is important to be able to write generic algorithms on IntegerArithmeticType. Are there any reasons it shouldn't?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

I think there is some sort of documentation or work being done on Number
Types in Swift to make it a more robust solution rather than the bunch of
lop-sided classes we have right now.

···

*___________________________________*

*James⎥Lead Engineer*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Jan 28, 2016 at 11:24 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

I agree, I think this would require all integer types to have mandatory
init(_:IntMax), init(_:UIntMax), init(truncatingBitPattern:IntMax) and
init(truncatingBitPattern:UIntMax) constructors? Would make working with
arbitrary sized integers in a generic way a lot easier.

On 28 Jan 2016, at 04:02, Patrick Pijnappel via swift-evolution < > swift-evolution@swift.org> wrote:

It seems IntegerArithmeticType should have a conversion from IntMax, in
analogy with Signed/UnsignedIntegerType. It already has toIntMax(), but
not the reverse conversion. This is important to be able to write generic
algorithms on IntegerArithmeticType. Are there any reasons it shouldn't?
_______________________________________________
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

5

That's looking really good, great work! Any idea how far we are from having
this in the language?

Kind regards,
Patrick

···

On Fri, Jan 29, 2016 at 5:50 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Thu Jan 28 2016, James Campbell <swift-evolution@swift.org> wrote:

> I think there is some sort of documentation or work being done on Number
> Types in Swift to make it a more robust solution rather than the bunch of
> lop-sided classes we have right now.

https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb

HTH,

--
-Dave

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

6

That's looking really good, great work! Any idea how far we are from having
this in the language?

There are *at least* a couple of weeks' work to clear out the parts
we've decided not to pursue and sculpt a few of the APIs we're not quite
happy with; then it all has to go through review on this list. And of
course, things have a way of coming up, so I would be wary of drawing
any hard conclusions here.

···

on Thu Jan 28 2016, Patrick Pijnappel <swift-evolution@swift.org> wrote:

Kind regards,
Patrick

On Fri, Jan 29, 2016 at 5:50 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Thu Jan 28 2016, James Campbell <swift-evolution@swift.org> wrote:

> I think there is some sort of documentation or work being done on Number
> Types in Swift to make it a more robust solution rather than the bunch of
> lop-sided classes we have right now.

https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb

HTH,

--
-Dave

_______________________________________________
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

--
-Dave