[swift-evolution] Epic: Typesafe calculations

Dave Abrahams dabrahams at apple.com
Thu Dec 31 11:25:50 CST 2015


> On Dec 25, 2015, at 4:43 PM, Nickolas Pohilets via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at 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 <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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-Dave

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


More information about the swift-evolution mailing list