<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 4:08 PM, Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 1:45 PM, Robert Widmann <<a href="mailto:rwidmann@apple.com" class="">rwidmann@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">As I was saying, I agree with the overall usefulness of <font face="Menlo" class="">newtype</font>-style declarations, but I don’t understand why we need so much syntax for what should just be a pattern in Swift. Specifically, the idea of automatic delegation of an interface is antithetical to the very reason why Haskell has <font face="Menlo" class="">newtype</font> in the first place. And in the situations in which I would create an <font face="Menlo" class="">alter</font>nate definition of a type, I expect to <i class="">never</i> inherit the interface of the underlying type because I intend for it to be completely distinct. </div></div></div></blockquote><div class=""><br class=""></div><div class="">What would this pattern look like?</div></div></div></div></blockquote><div><br class=""></div><div>Today, a struct wrapping a single stored property will give you both the static and dynamic semantics you’re looking for. All that’s left is the delegation.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">An alternative inherits nothing by default. You have to explicitly publish members from the underlying type to the current one. And you don’t have to; you can leave members out, or implement trampolines yourself. I wanted something between Go’s taking everything and C++’s taking nothing, more selectable like Haskell. (But I don’t really understand Haskell.)</div></div></div></div></blockquote><div><br class=""></div><div>Haskell’s <font face="Menlo" class="">newtype</font> feature does not provide this kind of delegation. It’s in the “taking nothing” camp.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Additionally, the use of inheritance in <font face="Menlo" class="">alter</font>nate definitions seems out of place and the casting section breaks encapsulation.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Enumerations use similar syntax to specify their raw type. What word, which may have to be new, should be used to serve a similar function as “super” within the main initializer?</div></div></div></div></blockquote><div><br class=""></div><div>Treating an <font face="Menlo" class="">alter</font>nate like a protocol is fine - there is prior art in protocols for that. But having alternatives refine each other doesn’t make much sense to me without a more salient example than the one in the proposal. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Isn’t breaking (or at least bending) encapsulation a point of casting? And shorter than calling “rawValue” and/or “init?” a bunch of times?</div></div></div></div></blockquote><div><br class=""></div><div>A cast in C and C++ may be so, but we encourage checked casts where possible and allow you access to the old “a promise to the compiler” kind of casting with <font face="Menlo" class="">unsafeBitCast</font> - and even then we check sizes. We should try to avoid leaking implementation details like this.</div><div><br class=""></div><div>~Robert Widmann</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div></div><br class=""><div class=""><blockquote type="cite" class=""></blockquote></div></div></div></div></div></blockquote></div><br class=""></body></html>