[swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

[Daryle Walker]

> On Jul 31, 2017, at 8:38 PM, Robert Widmann <rwidmann at apple.com> wrote:
> 
>> On Jul 31, 2017, at 4:08 PM, Daryle Walker <darylew at mac.com <mailto:darylew at mac.com>> wrote:
>> 
>>> On Jul 31, 2017, at 1:45 PM, Robert Widmann <rwidmann at apple.com <mailto:rwidmann at apple.com>> 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/7259ca13/attachment.html>