> On Jul 31, 2017, at 8:38 PM, Robert Widmann <[email protected]> wrote: > >> On Jul 31, 2017, at 4:08 PM, Daryle Walker <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Jul 31, 2017, at 1:45 PM, Robert Widmann <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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. >
It’s more for being orthogonal; there’s no reason to ban it. Whatever value type you have: give me equal or fewer states and a clean break in the interface (which can be selectively added back). It doesn’t matter which kind of value type the source was. I guess almost no-one would cast more than to/from the immediate underlying type, but the very design of alternatives lets me do multiple levels for free. Type punning is generally the only thing needed, no code except for downcasts (or the downcast phase of cross-casts) of non-basic alternatives, which must be kept for safety. >> 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. — 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
