Same as Dave "<font size="2"><span style="background-color:rgba(255,255,255,0)">+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."</span></font><br><br>On Wednesday, 20 January 2016, Dave via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+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.<br>
<br>
- Dave Sweeris<br>
<br>
> On Jan 15, 2016, at 09:51, Chris Lattner via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Jan 15, 2016, at 2:46 AM, Haravikk via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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.<br>
><br>
> Yes, it is.<br>
><br>
>> 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).<br>
><br>
> This is also my desire.<br>
><br>
> DaveA and Max have a tentative plan to improve integer semantics in these phases:<br>
><br>
> 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.<br>
><br>
> 2. Improve the numerics related protocols to enable writing generic code over different width types.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> -Chris<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><br><br>-- <br> -- Howard.<br><br>