[swift-evolution] undefined

[James Campbell]

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 at supmenow.com <james at 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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/f0a1785f/attachment.html>