[swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal
Robert Widmann
rwidmann at apple.com
Mon Jul 31 12:37:51 CDT 2017
I agree with the overall usefulness of newtype-style (
> On Jul 29, 2017, at 4:01 PM, Daryle Walker via swift-evolution <swift-evolution at swift.org> wrote:
>
> Proposal at <https://gist.github.com/CTMacUser/c493f775075e946efdcfd85d38473291 <https://gist.github.com/CTMacUser/c493f775075e946efdcfd85d38473291>>, uploaded revision 4.
>
> Changes:
>
> Since the original setup was a poor copy of how raw-style enumerations use RawRepresentable, changed the model to actually use RawRepresentable. Actually, it uses a sub-protocol, AnyAlternative, which adds an associated type for the implementing non-alternative type. AnyAlternative also serves a function like AnyObject.
> Removed the old library support type since it’s obsolete. Added back a (now global) function to upcast to the implementation type without needing to name it.
> Added option to initialize alternative by assigning to “super.” Using “super” by itself isn’t allowed in the grammar (It has to be followed by a member specification), so I added it.
> Added note about pointer compatibility.
> The model change led to a lot of rewording. And new/changed technical terms.
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/ac66cd41/attachment.html>
More information about the swift-evolution
mailing list