> On Jul 31, 2017, at 1:45 PM, Robert Widmann <[email protected]> wrote: > > As I was saying, I agree with the overall usefulness of newtype-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 > newtype in the first place. And in the situations in which I would create an > alternate definition of a type, I expect to never inherit the interface of > the underlying type because I intend for it to be completely distinct.
What would this pattern look like? 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.) > Additionally, the use of inheritance in alternate definitions seems out of > place and the casting section breaks encapsulation. 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? Isn’t breaking (or at least bending) encapsulation a point of casting? And shorter than calling “rawValue” and/or “init?” a bunch of times? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
