> On Jul 31, 2017, at 4:08 PM, Daryle Walker <[email protected]> wrote: > >> On Jul 31, 2017, at 1:45 PM, Robert Widmann <[email protected] >> <mailto:[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?
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. > > 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.) Haskell’s newtype feature does not provide this kind of delegation. It’s in the “taking nothing” camp. > >> 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? Treating an alternate 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. > > Isn’t breaking (or at least bending) encapsulation a point of casting? And > shorter than calling “rawValue” and/or “init?” a bunch of times? 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 unsafeBitCast - and even then we check sizes. We should try to avoid leaking implementation details like this. ~Robert Widmann > > — > 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
