<div dir="ltr">@Howard: While we are at implementation details: I think this is the typical case of what type theorists call "structural equivalence". You can think of Newton as a typedef (alias) for kg * m / s^2. Hence, if the compiler can look this info up, it can most definitely determine that they are the same and so is m * kg / s / s.<div><br></div><div>Yes, care needs to be taken about the associativity and commutativity of multiplication of units, but that's not too hard either, it basically amounts to some pattern matching along with symbolic computations respecting algebraic identities (think of it as a compile-time "unit interpreter") and maybe some post-normalization.</div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 29, 2015 at 9:12 AM, Austin Zheng via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1; first-class affordances to make dimensional analysis possible would be incredibly useful.<br>
<br>
Austin<br>
<div class="HOEnZb"><div class="h5"><br>
> On Dec 29, 2015, at 12:11 AM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> +1 for the ability to unit check expressions. It is harder to do than it sounds because there are many equivalent units, for example force N = mass kg * acceleration m/s^2. Therefore N, kg m/s^2, m/s^2 kg, etc. are all equal.<br>
><br>
> Sent from my iPad<br>
><br>
>> On 28 Dec 2015, at 9:33 AM, Greg Titus via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> On Dec 27, 2015, at 2:56 AM, Tino Heth <<a href="mailto:2th@gmx.de">2th@gmx.de</a>> wrote:<br>
>>><br>
>>><br>
>>>> There’s some unfortunate extra boilerplate here, which could be better handled with newtype support in the language, but when compiled with optimizations the resulting code is nearly identical to using plain Ints.<br>
>>><br>
>>> Cool — have you checked the generated assembler for this conclusion? But I guess there is some knowledge on how to build an optimizing compiler in the core team ;-), so I'd expect little to no penalty (I guess the memory footprint of plain Ints is still better).<br>
>><br>
>> Yes, I have, and actually, the memory footprint is no different! These are value-types that are exactly word-sized, and so get passed around in registers and stored inline in larger structs.<br>
>><br>
>> - Greg<br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#000000" face="monospace" size="3">Author of the Sparkling language</font><div><font color="#000000" face="monospace" size="3"><a href="http://h2co3.org" target="_blank">http://h2co3.org/</a><br></font></div><div><font color="#000000" face="monospace" size="3"><br></font></div></div></div>
</div>