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.
- 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
