<div>On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>Somewhat related to this, shouldn’t it be possible to sub-struct a struct as long as you only add functions and computed properties (i.e., no stored properties)? Traditionally structs cannot be subtyped because their size must be known at compile time. I don’t know the implementation details of where functions and computed properties live, but something tells me they belong to the type and not the object (although I’ve never really made the effort to sit down and fully understand Swift’s type model), in which case adding them to a struct’s definition would not change the size of the object on the stack. Thus it should be possible to make custom substructs of String that add additional functionality but no new stored properties. Thoughts?</div></div></blockquote><div><br></div><div>Value subtyping is a large subject and, IIUC, newtype would be a subset of that topic. Unlikely to be in scope for Swift 5, though, but that’s up to the core team.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite"><div>On Jun 9, 2017, at 9:53 AM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>> wrote:</div><br class="m_8809170826063233257Apple-interchange-newline"><div><div style="word-wrap:break-word">-1 - this would disallow e.g. to share UI code between iOS and macOS:<div><br></div><div>#if os(iOS)</div><div><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>typealias XUView = UIView</div><div>#else</div><div><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>typealias XUView = NSView</div><div>#endif</div><div><br></div><div>extension XUView {</div><div><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>...</div><div>}</div></div></div></blockquote><br><div>I really don’t see how this disallows code sharing between the two systems? Could you explain further? Based on my understanding of the pitch, this is valid code still. (Although I do like the suggestion of a new keyword rather than just limiting type alias).</div><div><br></div><div>Even if your example was invalid, you could also just do something like this:</div><div><br></div><div><font face="Menlo">#if os(iOS)</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>typealias XUView = UIView</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>extension XUView {</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>//extension code here</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>}</font></div><div><font face="Menlo">#if os(macOS)</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>typealias XUView = UIView</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>extension XUView {</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>// extension code here</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>}</font></div><div><font face="Menlo">#endif</font><br><div><br></div><div>While not as pretty, still just as effective if you have to deal with different types based on the system being compiled for and you could easily still make the type alias extensions for each type work the same.</div><div><br><div><blockquote type="cite"><div>On Jun 9, 2017, at 9:53 AM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>> wrote:</div><br class="m_8809170826063233257Apple-interchange-newline"><div><div style="word-wrap:break-word">-1 - this would disallow e.g. to share UI code between iOS and macOS:<div><br></div><div>#if os(iOS)</div><div><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>typealias XUView = UIView</div><div>#else</div><div><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>typealias XUView = NSView</div><div>#endif</div><div><br></div><div>extension XUView {</div><div><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>...</div><div>}</div><div><br></div><div>or with any similar compatibility typealiases.</div><div><br><div><blockquote type="cite"><div>On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8809170826063233257Apple-interchange-newline"><div><div style="word-wrap:break-word">+1 from me.<div><br></div><div>There have been times I’ve wanted to subclass an object (such as String) but since it is a non-class, non-protocol type you can only extend Strings existing functionality which adds that same functionality to Strings everywhere. It would be nice if we could either extend type aliases (and only the type alias), or if it were possible to inherit from structs so that we could create a custom string type like so:</div><div><br></div><div><font face="Menlo">struct HeaderKey: String {</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>static var lastModified: String { return “Last-Modified” }</font></div><div><font face="Menlo"><span class="m_8809170826063233257Apple-tab-span" style="white-space:pre-wrap"> </span>static var host: String { return “Host” }</font></div><div><font face="Menlo">}</font></div><div><br></div><div>I realize that struct inheritance is far less likely, since that defeats one of the main pieces of what makes a struct a struct. So I’m all for this proposal of allowing type aliases to be extended as though they were their own struct/class.</div><div><br></div><div>Unfortunately, I’m not sure how feasible this kind of functionality would actually be, but if it’s possible then I’m in favor of implementing it.</div><div><br><div><blockquote type="cite"><div>On Jun 8, 2017, at 10:14 PM, Yvo van Beek via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8809170826063233257Apple-interchange-newline"><div><div>Typealiases can greatly reduce the complexity of code. But I think one change in how the compiler handles them could make them even more powerful.<div><br></div><div>Let's say I'm creating a web server framework and I've created a simple dictionary to store HTTP headers (I know that headers are more complex than that, but as an example). I could write something like this:</div><div><br></div><div><div> <font face="monospace, monospace" color="#0b5394">typealias HeaderKey = String</font></div><div><font face="monospace, monospace" color="#0b5394"><br></font></div><div><font face="monospace, monospace" color="#0b5394"> var headers = [HeaderKey: String]()</font></div><div><font face="monospace, monospace" color="#0b5394"> headers["Host"] = "<a href="http://domain.com/" target="_blank">domain.com</a>"</font></div></div><div><br></div><div>Now I can define a couple of default headers like this:</div><div><br></div><div><div><font color="#0b5394" face="monospace, monospace"> extension HeaderKey {</font></div><div><font color="#0b5394" face="monospace, monospace"> static var lastModified: String { return "Last-Modified" }</font></div><div><font color="#0b5394" face="monospace, monospace"> static var host: String { return "Host" }</font></div><div><font color="#0b5394" face="monospace, monospace"> }</font></div></div><div><br></div><div>After that I can do this:<br></div><div><br></div><div><div><span style="color:rgb(11,83,148);font-family:monospace,monospace"> </span><font color="#0b5394"><font face="monospace, monospace">var headers = [HeaderKey: String]()</font></font></div><div><span style="color:rgb(11,83,148);font-family:monospace,monospace"> </span><font face="monospace, monospace" color="#0b5394">headers[.host] = "<a href="http://domain.com/" target="_blank">domain.com</a>"</font></div><div><span style="color:rgb(11,83,148);font-family:monospace,monospace"> </span><font face="monospace, monospace" color="#0b5394">headers[.lastModified] = "some date"</font><font face="monospace, monospace" color="#0b5394"><br></font></div><div><span style="color:rgb(11,83,148);font-family:monospace,monospace"> </span><font face="monospace, monospace" color="#0b5394">headers["X-MyHeader"] = "This still works too"</font></div></div><div><font face="monospace, monospace" color="#0b5394"><br></font></div><div>But unfortunately the extension is also applied to normal strings:<font face="monospace, monospace" color="#0b5394"><br></font></div><div><br></div><div> <font color="#0b5394" face="monospace, monospace">var normalString: String = .host</font><br></div><div><font color="#0b5394" face="monospace, monospace"><br></font></div><div>Perhaps it would be better if the extension would only apply to the parts of my code where I use the HeaderKey typealias and not to all Strings. This could be a great tool to specialize classes by creating a typealias and adding functionality to it. Another example I can think of is typealiases for dictionaries or arrays with added business logic through extensions (especially since you can't inherit from structs).<font color="#0b5394" face="monospace, monospace"><br></font></div><div><br></div><div>If you want to create an extension that adds functionality to all Strings you could have created an extension for String instead of HeaderKey.</div><div><br></div><div>Please let me know what you think. I'm not sure how complex this change would be.</div><div>I could write a proposal if you're interested.</div><div><br></div><div>Kind regards,</div><div>Yvo</div></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>