> On Dec 25, 2015, at 4:43 PM, Nickolas Pohilets via swift-evolution > <[email protected]> wrote: > > 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 > <http://www.boost.org/doc/libs/1_60_0/doc/html/boost_units.html>) available > in Swift.
Yes, that’s an excellent design. We really want to do this when we get the necessary language features (I hope we might also come up with some that improve readability a bit over what you can do in C++). > > 2015-12-25 4:36 GMT+01:00 Stephen Christopher via swift-evolution > <[email protected] <mailto:[email protected]>>: > 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] <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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
