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…

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.

There's been discussion of this before, actually. Search the archives for `newtype`, which is Haskell's version of this feature.

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.

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.

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…

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.

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.

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…

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).
I have been playing with something similar, but using enums instead of structs (I thought it's nice to model different units for the same quantity).
With generics and protocols, it is already possible to do simple calculations without to much overhead, and maybe I'll create a library for the most important physical quantities with this toolset.

I'm still trying to figure out if there is a clever trick to model compound units (velocity as m/s, for example) in a general way:
It is simple to express that UnitA * UnitB is equal to UnitB * UnitA, but it gets tedious when there are many units and factors…

I have to agree to Matthew that this list isn't the ideal place for everything:
It is easy to loose track, and good ideas might get lost.

Besides publishing my own experiments on what is possible already, I took a look on the tools offered by github — and imho it is an option to be considered.
So, if anyone wants to store his thoughts in a wiki, or publish playgrounds ands normal projects, please take a look athttps://github.com/orgs/SwiftTypesafeCalculations/teams/staff

I've never used github for serious collaboration before, but I'd expect that you can just join and start using the resources.

If someone has an alternative or an idea for a better structure at github, please write about it or ask for a takeover of the organization (or create one on your own if you come up with a better name)

I hope there's still some interest in the topic (or in the cartwheels-video Matt promised and just finished the draft for a first proposal.
Instead of trying to turn typealias into some sort of newtype, which leaves a lot more questions open as I thought originally, I started with "compile-time parameters":
The name of the feature can be discussed (as well as its details), but it would not only add typesafety to matrix, vector, tensor and other entities, but also offer a simple way to handle computations with physical quantities (three of those should be sufficient in most cases, so the idea mentioned by Thorsten should work fine).

I still haven't taken the time to take a detailed look at boost units, but I would be glad if someone with practical experience could contribute to the proposal — the same is true for all other parts, as I'd happily turn the document into a joint paper (I'm not sure, but maybe it could even become the first multi-author submission

Something like class delegation in Kotlin?
Please hurry, I've no work to distract me for the rest of the year, and extending typealias could be a very quick proposal

Details are still brewing. I am not familiar with class delegation in Kotlin but will look it up. Thanks for mentioning it!

I plan to spend a lot of time on Swift proposal work over the next week and a half but can't make any promises on timing. I made that mistake with my proposal on flexible memberwise initialization which ended up taking a couple weeks longer than I expected (for several reasons). What I can say is that this is pretty high on my Swift proposal priority list.

I have been working for a couple weeks (since the previous [newtype
discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html)
) on a related pitch. There seem to me to be multiple ways to solve this
problem - a newtype(esque) keyword, struct subtyping, or forwarding as
Matthew is suggesting. I’d hoped to have a discussion starter out before
the holidays, but it takes a fair amount of work to put together even a
decent draft for a proposal. This is top of my list currently for a way to
contribute though. Looking forward to the ensuing discussions.

Thanks for the pointer on class delegation. I’ve looked at delegated
properties there (which came up in relation to Joe’s recent proposal for
behaviors on properties).

> On Dec 24, 2015, at 1:07 PM, Tino Heth <2th@gmx.de> wrote:
>
>
>> I'm planning to write a proposal for automatic forwarding.
> Something like class delegation in Kotlin?
> Please hurry, I've no work to distract me for the rest of the year, and
extending typealias could be a very quick proposal

Details are still brewing. I am not familiar with class delegation in
Kotlin but will look it up. Thanks for mentioning it!

I plan to spend a lot of time on Swift proposal work over the next week
and a half but can't make any promises on timing. I made that mistake with
my proposal on flexible memberwise initialization which ended up taking a
couple weeks longer than I expected (for several reasons). What I can say
is that this is pretty high on my Swift proposal priority list.

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

I have to agree to Matthew that this list isn't the ideal place for
everything:
It is easy to loose track, and good ideas might get lost.

Besides publishing my own experiments on what is possible already, I took
a look on the tools offered by github — and imho it is an option to be
considered.
So, if anyone wants to store his thoughts in a wiki, or publish
playgrounds ands normal projects, please take a look athttps://github.com/orgs/SwiftTypesafeCalculations/teams/staff

I've never used github for serious collaboration before, but I'd expect
that you can just join and start using the resources.

If someone has an alternative or an idea for a better structure at github,
please write about it or ask for a takeover of the organization (or create
one on your own if you come up with a better name)

I have to agree to Matthew that this list isn't the ideal place for everything:
It is easy to loose track, and good ideas might get lost.

Besides publishing my own experiments on what is possible already, I took a look on the tools offered by github — and imho it is an option to be considered.
So, if anyone wants to store his thoughts in a wiki, or publish playgrounds ands normal projects, please take a look athttps://github.com/orgs/SwiftTypesafeCalculations/teams/staff

It would be possible to keep the parameters in the initializer (or function) and mark them with a keyword: init(static dimensions: Int) {...

got me thinking. What if parameters marked with static, or constexpr, or some such, could complement template parameters, rather than being an alternative to them. Basically, stuff between the angle brackets is relevant for determining storage needed, and other constexpr parameters enable arbitrary compile time checks. I hope the mailing list doesn’t mind a little brainstorming about these further off features. Probably easiest to explain myself in terms of the matrix example:

struct AntisymmetricMatrix: InvertibleMatrix where {
//more complicated restriction clause, something like a
//compile time predicate/closure, which operates on member variables that are constexprs
for i in 0..<Dim{
for j in 0..<Dim{
static_assert(entries[i][j] == -entries[j][i], “invalid entries”);
}
}

//and another:
typespecialization InvertibleMatrix = SquareMatrix where determinant() != 0
Some obvious drawbacks here are long compile times (eg, computing a 10x10 determinant), and of course many situations where you can’t know things at compile time so this doesn’t help you. But I think it’s an interesting direction to look at. A type system with such capabilities, + playgrounds/REPLs, and you’ve got something akin to Mathematica, but without the mind-bending syntax.

I hope there's still some interest in the topic (or in the cartwheels-video Matt promised and just finished the draft for a first proposal.
Instead of trying to turn typealias into some sort of newtype, which leaves a lot more questions open as I thought originally, I started with "compile-time parameters":
The name of the feature can be discussed (as well as its details), but it would not only add typesafety to matrix, vector, tensor and other entities, but also offer a simple way to handle computations with physical quantities (three of those should be sufficient in most cases, so the idea mentioned by Thorsten should work fine).

I still haven't taken the time to take a detailed look at boost units, but I would be glad if someone with practical experience could contribute to the proposal — the same is true for all other parts, as I'd happily turn the document into a joint paper (I'm not sure, but maybe it could even become the first multi-author submission

I hope there's still some interest in the topic (or in the cartwheels-video Matt promised and just finished the draft for a first proposal.
Instead of trying to turn typealias into some sort of newtype, which leaves a lot more questions open as I thought originally, I started with "compile-time parameters":
The name of the feature can be discussed (as well as its details), but it would not only add typesafety to matrix, vector, tensor and other entities, but also offer a simple way to handle computations with physical quantities (three of those should be sufficient in most cases, so the idea mentioned by Thorsten should work fine).

I still haven't taken the time to take a detailed look at boost units, but I would be glad if someone with practical experience could contribute to the proposal — the same is true for all other parts, as I'd happily turn the document into a joint paper (I'm not sure, but maybe it could even become the first multi-author submission

well, it has to be decided yet if that document turns into a real proposal (but I hope so

got me thinking. What if parameters marked with static, or constexpr, or some such, could complement template parameters, rather than being an alternative to them. Basically, stuff between the angle brackets is relevant for determining storage needed, and other constexpr parameters enable arbitrary compile time checks. I hope the mailing list doesn’t mind a little brainstorming about these further off features.

imho the list is quite good at simply ignoring stuff it doesn't care for — but I would expect some feedback if you open a thread for the topic:
I'm still waiting for someone asking for compile-time execution with a reference tohttps://www.youtube.com/watch?v=UTqZNujQOlA <https://www.youtube.com/watch?v=UTqZNujQOlA>
(it's such a cool concept — we really should have a use case for it :), and your idea is a variant of this feature.

I have read several times that Swift 3 won't have macros, but have the impression that this is a huge topic, so even if proposals heading in this direction won't (most likely) be accepted now, they might become important next year.
As far as I know, some compilers are already clever enough to replace simple calculations (like secondsPerDay = 60*60*24; f = pi * 2.0;…), so it is not that strange to extend that concept.
In theory, this could work without new keywords (when all input is known at compile time, just evaluate), but as speed at runtime isn't always the most important aspect, some sort of hint might be better.

I'm sure that checks at compile-time would not only be useful for calculations:
NSURL, for example, can be initialized with a string that simply does not represent an URL (therefore, init can return nil). But if the parameter is a string literal, you'll always have the same result at runtime…

I have been working for a couple weeks (since the previous [newtype
discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html)
) on a related pitch. There seem to me to be multiple ways to solve this
problem - a newtype(esque) keyword, struct subtyping, or forwarding as
Matthew is suggesting. I’d hoped to have a discussion starter out before
the holidays, but it takes a fair amount of work to put together even a
decent draft for a proposal. This is top of my list currently for a way to
contribute though. Looking forward to the ensuing discussions.

Thanks for the pointer on class delegation. I’ve looked at delegated
properties there (which came up in relation to Joe’s recent proposal for
behaviors on properties).

> On Dec 24, 2015, at 1:07 PM, Tino Heth <2th@gmx.de> wrote:
>
>
>> I'm planning to write a proposal for automatic forwarding.
> Something like class delegation in Kotlin?
> Please hurry, I've no work to distract me for the rest of the year, and
extending typealias could be a very quick proposal

Details are still brewing. I am not familiar with class delegation in
Kotlin but will look it up. Thanks for mentioning it!

I plan to spend a lot of time on Swift proposal work over the next week
and a half but can't make any promises on timing. I made that mistake with
my proposal on flexible memberwise initialization which ended up taking a
couple weeks longer than I expected (for several reasons). What I can say
is that this is pretty high on my Swift proposal priority list.