This just popped up on HN and may be relevant to this discussion.
http://www.home.hs-karlsruhe.de/~fado0001/2015-32C3/paper-onecolumn-colour.pdf On Tue, Dec 29, 2015, 16:11 Howard Lovatt via swift-evolution < [email protected]> wrote: > +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. > > Sent from my iPad > > > On 28 Dec 2015, at 9:33 AM, Greg Titus via swift-evolution < > [email protected]> wrote: > > > > > >> On Dec 27, 2015, at 2:56 AM, Tino Heth <[email protected]> wrote: > >> > >> > >>> 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. > >> > >> 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). > > > > 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. > > > > - Greg > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
