Epic: Typesafe calculations

Evolution Discussion
1

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

2

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.

···

--
Brent Royal-Gordon
Architechies

3

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 <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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.

···

Sent from my iPad

On Dec 24, 2015, at 11:44 AM, Greg Titus via swift-evolution <swift-evolution@swift.org> wrote:

   - Greg

On Dec 24, 2015, at 4:28 AM, Tino Heth via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

Search the archives for `newtype`, which is Haskell's version of this feature

Thanks for the hint — searching the archives is more complicated as expected ;-), but afaics there haven't been any opposing statements, and the topic just died away without a formal proposal.

Any interest reviving it over the holydays?

tuuranton@tutanota.de: Small world… have you been to hackover in Hannover last year? ;-)

6

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

7

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…

Tino

8

Hi there!

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 at
https://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)

Best regards,
Tino

9

Hi there!

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

To make this easier, I created a wiki-page; this should be editable without forking a repository (I haven't figured out if a can give write permissions to everyone, so it might be necessary to click somewhere to request permissions).
The URL is

Happy collaboration!
Tino

10

My college calculator had that, and once I discovered it I never went back. For sure, if I did anything remotely scientific with Swift, I would be in love with the feature.

I'm not very good with functional programming but that sounds like something functional programming folks would have a solution for.

Félix

···

Le 24 déc. 2015 à 08:09:23, Tino Heth via swift-evolution <swift-evolution@swift.org> a écrit :

Search the archives for `newtype`, which is Haskell's version of this feature

Thanks for the hint — searching the archives is more complicated as expected ;-), but afaics there haven't been any opposing statements, and the topic just died away without a formal proposal.

Any interest reviving it over the holydays?

tuuranton@tutanota.de: Small world… have you been to hackover in Hannover last year? ;-)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

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.

Matthew

···

Sent from my iPad

On Dec 24, 2015, at 1:07 PM, Tino Heth <2th@gmx.de> wrote:

12

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

- Step Christopher

···

On Thu, Dec 24, 2015 at 2:40 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

Sent from my iPad

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

Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

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

···

On Dec 27, 2015, at 2:56 AM, Tino Heth <2th@gmx.de> 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).

14

Thanks Tino, I'll upload mine to that Repo shortly :)

···

On Thu, Jan 7, 2016 at 4:39 PM, Tino Heth <2th@gmx.de> wrote:

Hi there!

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 at
https://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)

Best regards,
Tino

--
 Wizard
james@supmenow.com
+44 7523 279 698

15

Heads-up: that URL gives a 404 (at least for me...)

Cheers,
M.

···

On 8 Jan 2016, at 00:39, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Hi there!

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 at
https://github.com/orgs/SwiftTypesafeCalculations/teams/staff

--
Mark Glossop
E: lists@cueballcentral.com
TW: http://twitter.com/Cueball_AU

16

Hi Tino, Thanks for making your proposal.

One of the points from your ‘alternatives considered’ section,

Marked parameters

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 Matrix<T:ScalarType, NRows:UInt, NCols:UInt>{
  let entries: [ScalarType]

  //note the initializer parameter marked as a constexpr,
  //which enables further compile time checks with a `where` clause
  init(entries: constexpr [ScalarType] where entries.count == NRows * NCols) {
    self.entries = entries
  }
  
  subscript(i:Int, j:Int) -> ScalarType{
    …
  }
}

typealias SquareMatrix = Matrix where NRows == NCols

extension SquareMatrix{
  static alias Dim = NRows//no additional storage
  func determinant() -> ScalarType{
    ...
  }
}

struct InvertibleMatrix: SquareMatrix where determinant() != 0
// ^~~ 'restriction’ clause, i.e., not inheritance;
// determinant() is executed at compile time,
// since `entries` is a constexpr

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”);
    }
  }
  
}

struct ComplexNumber: AntisymmetricMatrix<Dim: 2>
          where entries[0,0] == entries[1,1]
          && entries[0,1] == -entries[1,0]

struct Rotor: ComplexNumber where magnitude() == 1.0

func *(lhs:ComplexNumber, rhs:ComplexNumber) -> ComplexNumber{
  return ComplexNumber( entries: [lhs.entries[0,0]* …)
}

//another syntax option this feature:
typerestriction InvertibleMatrix = SquareMatrix where determinant() != 0

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

Matt

···

On Jan 12, 2016, at 06:22, Tino Heth <2th@gmx.de> wrote:

Hi there!

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

To make this easier, I created a wiki-page; this should be editable without forking a repository (I haven't figured out if a can give write permissions to everyone, so it might be necessary to click somewhere to request permissions).
The URL is
Compile time parameters · SwiftInofficialEvolution/Home Wiki · GitHub

Happy collaboration!
Tino

17

Hi Tino,

the real advantage is missing from the proposal :-)

With the proposal it should be possible to write

func<T, rows1, cols1, rows2, cols2 where cols1 == rows2>(lhs: Matrix<T, rows1, cols1>, rhs: Matrix<T, rows2, cols2>) -> Matrix<T, rows1, cols2>
{ … }

The example in the proposal just uses the static parameters for runtime checks which is no advantage over using init parameters.

-Thorsten

···

Am 12.01.2016 um 15:22 schrieb Tino Heth via swift-evolution <swift-evolution@swift.org>:

Hi there!

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

To make this easier, I created a wiki-page; this should be editable without forking a repository (I haven't figured out if a can give write permissions to everyone, so it might be necessary to click somewhere to request permissions).
The URL is
Compile time parameters · SwiftInofficialEvolution/Home Wiki · GitHub

Happy collaboration!
Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

Hello Matt!

Hi Tino, Thanks for making your proposal.

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 to
https://www.youtube.com/watch?v=UTqZNujQOlA <https://www.youtube.com/watch?v=UTqZNujQOlA&gt;
(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…

Best regards,
Tino

19

Wouldn't that only work for literal matrices?

-Thorsten

···

Am 12.01.2016 um 23:49 schrieb Matt Whiteside via swift-evolution <swift-evolution@swift.org>:

struct InvertibleMatrix: SquareMatrix where determinant() != 0
// ^~~ 'restriction’ clause, i.e., not inheritance;
// determinant() is executed at compile time,
// since `entries` is a constexpr

20

If Swift would support non-type generic parameters, then I would like to
have Boost.Unit library (
http://www.boost.org/doc/libs/1_60_0/doc/html/boost_units.html\) available
in Swift.

···

2015-12-25 4:36 GMT+01:00 Stephen Christopher via swift-evolution < swift-evolution@swift.org>:

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

- Step Christopher

On Thu, Dec 24, 2015 at 2:40 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

Sent from my iPad

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

Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution