[swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal
gor.f.gyolchanyan at icloud.com
Sun Jul 30 01:29:04 CDT 2017
I feel like I should mention that Clang has __attribute__((__swift_newtype__)) type attribute that replaces the imported type from typealias to a new RawRepresentable struct. Clang has a variety of poorly documented swift compatibility extensions like this (a lot of which I managed to discover, play with and determine the effect myself). I think this should be mentioned in your proposal, because it looks like this Clang attribute is begging to be re-modeled to use your alters.
> On Jul 30, 2017, at 2:01 AM, 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution