<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">FWIW I began a draft for a newtype/wrapper-synthesis proposal but abandoned it due to:</div><div class=""><br class=""></div><div class="">- (a) perceived lack of community interest&nbsp;</div><div class="">- (b) running into *serious* complications around associated types</div><div class=""><br class=""></div><div class="">…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).&nbsp;</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">In that specific case, you *probably* want this:</div><div class=""><br class=""></div><div class="">- `Foo.Element` == `Bar.Element`</div><div class="">- `Foo.Index` == a *newtype* of `Bar.Index` (e.g., not just a bare `Bar.Index`)</div><div class="">- `Foo.Generator` == `Bar.Generator` (I assume)</div><div class="">- `Foo.SubSequence` ==&nbsp;</div><div class="">&nbsp; - `Foo`, when `Bar.SubSequence` == `Bar`</div><div class="">&nbsp; - `Slice&lt;Foo&gt;`, when `Bar.SubSequence` == `Slice&lt;Bar&gt;`</div><div class="">&nbsp; - a *newtype* of `Bar.SubSequence`, when `Bar.SubSequence` is some other type</div><div class=""><br class=""></div><div class="">…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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 24, 2015, at 9:36 PM, Stephen Christopher via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I have been working for a couple weeks (since the previous [newtype discussion](<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html</a>) ) 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.<div class=""><br class=""></div><div class="">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).</div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class="">- Step Christopher<div class=""><br class=""></div><div class=""></div><div class=""><br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Thu, Dec 24, 2015 at 2:40 PM, Matthew Johnson via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
<br class="">
Sent from my iPad<br class="">
<span class=""><br class="">
&gt; On Dec 24, 2015, at 1:07 PM, Tino Heth &lt;<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>&gt; wrote:<br class="">
&gt;<br class="">
&gt;<br class="">
&gt;&gt; I'm planning to write a proposal for automatic forwarding.<br class="">
&gt; Something like class delegation in Kotlin?<br class="">
&gt; Please hurry, I've no work to distract me for the rest of the year, and extending typealias could be a very quick proposal ;-)<br class="">
<br class="">
</span>Details are still brewing.&nbsp; I am not familiar with class delegation in Kotlin but will look it up.&nbsp; Thanks for mentioning it!<br class="">
<br class="">
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.&nbsp; 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).&nbsp; What I can say is that this is pretty high on my Swift proposal priority list.<br class="">
<br class="">
Matthew<br class="">
<div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=9EwXyNl81W9TT3yZ17PL28-2Be7Ks-2FXLjqa0dZcsddi5Z9WTws7D35xbGnt1o49JEBtKw9PM0-2FDk5dWMy-2FZuvQDGRkocYShPKsapVATGTCy-2BEZFHSfjD-2F36Y8ArNr5j7HuZ-2FbCngNyuaWkUBHSZs5PEegF32Hd-2FPE-2FKBQrlRIOCUVOm7ZL7KJFqnPpc4GerVatiqKFpGAIvfER8lBsxzHYcg-2FsKN9Q9ljuall44i-2BV9-2Fo-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>