Sent from my iPad
> On Dec 24, 2015, at 11:44 AM, Greg Titus via swift-evolution > <[email protected]> wrote: > > First, of all, I’d love to have a “newtype” equivalent in Swift: +1. > > But also wanted to mention that my current pattern for this sort of code is > to use structs, which has the added advantage (or disadvantage, depending > upon your particular use case) of being able to easily specify fewer and more > specific valid operators than the “real” underlying type. > > For instance, some (real project scheduling) code, where you can add or > subtract a Duration from a TimeOfDay, and you can get the difference between > two TimeOfDays as a Duration, but to add two TimeOfDays is nonsensical. > > struct TimeOfDay : Comparable { > let t: Int // in seconds > } > struct Duration : Comparable { > let d: Int // in seconds > } > func +(lhs: TimeOfDay, rhs: Duration) -> TimeOfDay { > return TimeOfDay(lhs.t + rhs.d) > } > func -(lhs: TimeOfDay, rhs: Duration) -> TimeOfDay { > return TimeOfDay(lhs.t - rhs.d) > } > func -(lhs: TimeOfDay, rhs: TimeOfDay) -> Duration { > return Duration(lhs.t - rhs.t) > } > > 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. And > almost all higher level code ends up using these types naturally without > needing to unwrap them to Int, so there are fewer accesses to the underlying > real types than you would think. > > It would be great if any proposal involving newtype covered specifying > allowable operators defined on such types to support this kind of thing. I'm planning to write a proposal for automatic forwarding. My intent is that it will cover many use cases including newtype. It's still in the concept phase in my mind but I think you will be very pleased if the details work out as I hope and it is eventually accepted. > > - Greg > >> On Dec 24, 2015, at 4:28 AM, Tino Heth via swift-evolution >> <[email protected]> wrote: >> >> Hi there, >> >> this is a kind of survey for general interest that could lead to several >> separate proposals — at least one would address a real-world problem with >> evident fatal consequences (or instead of proposals, we might end up with >> clever patterns to handle the problems better). >> >> Right now, it's possible to do type-safe math with Swift, but afaics, it is >> impractical because the language lacks support for this. >> >> Let's say I want to express the concepts of temperature and mass. >> I can declare >> let t: Float = 100.0 >> let m: Float = 1 >> and work with those — but the values are just plain numbers, and can be used >> in a way that makes no sense (addition of temperature and mass, for example) >> >> We can't subclass structs like Float, and typealias has very limited use, >> because it's really just what it says: A new name without special features >> that can be used mutually interchangeable with the "real" type. >> >> A first tiny step towards more safety would be empowering typealias and >> generate warnings when a function is used with the "wrong" parameter type >> ("Kelvin" requested, but plain Float given). >> Additionally, extensions written for a typealias shouldn't be treated like >> extensions for the underlying type. >> An extra benefit of this would be the possibility to have >> typealias Path = String >> and make a clean distinction between general String-methods and those that >> are only relevant for Strings that represent a Path in the file system — it >> would even be possible to generate failable initializers to document >> constraints of the "new" type. >> >> I know that issues because of wrong units are something the average >> iOS-developer seldom cares for, but as I said above: >> Bugs that only could happen because of missing typesafety in calculations >> caused disasters that make memory leaks and race conditions look ridiculous >> trivial. >> >> Originally, I planned to broaden the topic much more than I did, but as >> community reaction sometimes is quite mysterious to me, focusing on one >> aspect might be better… >> >> So, any opinions, or even arguments against typesafe math? >> >> Merry christmas! >> Tino >> _______________________________________________ >> 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
