[swift-evolution] Simplified Conversion of Integer Types

[Howard Lovatt]

Same as Dave "+1 for all three, and +1 for introducing sub-typing for
structs and enums, for those times when you want sub-typing *and* value
semantics."

On Wednesday, 20 January 2016, Dave via swift-evolution <
swift-evolution at swift.org> wrote:

> +1 for all three, and +1 for introducing sub-typing for structs and enums,
> for those times when you want sub-typing *and* value semantics.
>
> - Dave Sweeris
>
> > On Jan 15, 2016, at 09:51, Chris Lattner via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >
> > On Jan 15, 2016, at 2:46 AM, Haravikk via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >>
> >> Something that’s still an annoyance to me in Swift is conversion
> between different integer types, both by size and signed vs. unsigned, as
> many mismatches result in errors requiring either refactoring to one common
> type, or boiler-plate to cast the values.
> >
> > Yes, it is.
> >
> >> I’d like to propose that Swift implicitly cast values to an integer
> type with a larger size (so in this case there is no error as an Int64 is
> larger than an Int16).
> >
> > This is also my desire.
> >
> > DaveA and Max have a tentative plan to improve integer semantics in
> these phases:
> >
> > 1. Improve the comparison and shift operators to not require symmetry.
> You should be able to do “someUInt == someInt” and get a proper value
> comparison.
> >
> > 2. Improve the numerics related protocols to enable writing generic code
> over different width types.
> >
> > 3. Introduce subtyping relationships between the integers and the floats
> so that we can implicit promotions from smaller to wider types.  This can
> either be done with a general language feature to introduce subtyping of
> structs/enums or by hacking it into the compiler, different folks have
> different opinions on how this will work, and it isn’t designed yet.
> >
> > The first two are a strong goal for swift 3, the later is "nice to have”
> if it fits since it is “just” sugar and there is a lot of other stuff going
> on.  We are also interested in introducing a proper BigInt type, but that
> is even “nicer to have” for Swift 3.
> >
> > -Chris
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/a86d9638/attachment.html>