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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
