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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> wrote: > > > Sent from my iPad > > > On Dec 24, 2015, at 1:07 PM, Tino Heth <[email protected] <mailto:[email protected]>> > > 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > 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
