[swift-evolution] Epic: Typesafe calculations

[Matthew Johnson]

Sent from my iPad

> On Dec 24, 2015, at 11:44 AM, Greg Titus via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution