[swift-evolution] Epic: Typesafe calculations

[plx]

FWIW I began a draft for a newtype/wrapper-synthesis proposal but abandoned it due to:

- (a) perceived lack of community interest 
- (b) running into *serious* complications around associated types

…note that this *didn’t* directly-address any sort of units system, but would be somewhat complementary (and a good first step in that direction). 

The short version of the issue in (b) is that whereas the desired behavior-and-semantics for “direct" newtype/wrapper-style constructs — where `Foo` is a newtype of `Bar` — seem pretty straightforward to specify, that’s not enough; you also have to deal with the “indirect” scenario, e.g. with situations in which `Foo` is a newtype of `Bar`, but `Bar` is also a `CollectionType`, and you want `Foo` to also be a `CollectionType` (or any other similar case).

In that specific case, you *probably* want this:

- `Foo.Element` == `Bar.Element`
- `Foo.Index` == a *newtype* of `Bar.Index` (e.g., not just a bare `Bar.Index`)
- `Foo.Generator` == `Bar.Generator` (I assume)
- `Foo.SubSequence` == 
  - `Foo`, when `Bar.SubSequence` == `Bar`
  - `Slice<Foo>`, when `Bar.SubSequence` == `Slice<Bar>`
  - a *newtype* of `Bar.SubSequence`, when `Bar.SubSequence` is some other type

…and although you can quibble with the exact choices here, the general issue is that it’s seemingly quite hard to really achieve the type-safety goals for some newtype/wrapper proposal without also addressing how to potentially “re-wrap” the wrapped type’s associated types.

It can be done I’m sure, but it’s seemingly rather involved; it definitely feels like a “Swift 4 (or later)” feature. If there’s enough community interest I could pick it up and flesh it out a bit more.

> On Dec 24, 2015, at 9:36 PM, Stephen Christopher via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 
> Sent from my iPad
> 
> > On Dec 24, 2015, at 1:07 PM, Tino Heth <2th at gmx.de <mailto:2th at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151229/ecc2e2ef/attachment.html>