Any/AnyObject are constraints for an existential container. Protocol conformances are also existential constraints, but not quite the same thing as Any/AnyObject.
Rather than adding negative constraints, I think we need a richer set of more specific positive constraints.
- Karl
···
On Aug 1, 2017 at 12:50 am, <Daryle Walker via swift-evolution (mailto:swift-evolution@swift.org)> wrote:
>
> On Jul 31, 2017, at 1:49 PM, Robert Widmann <rwidmann@apple.com (mailto:rwidmann@apple.com)> wrote:
>
>
>
> >
> > On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution <swift-evolution@swift.org (mailto:swift-evolution@swift.org)> wrote:
> >
> >
> >
> >
> >
> > Part of the response that closed [SR-5589] as “Won’t Do” was:
> >
> >
> >
>
>
>
> >
> >
> >
> >
> >
> >
> > > AnyObject is no longer a protocol
> >
> >
> >
> >
> > Then, what is it?
> >
> >
> >
>
>
>
> Relevant [WIP] Remove AnyObject protocol by slavapestov · Pull Request #8749 · apple/swift · GitHub
>
So… it got moved one layer down of indirection?
Hmm, what would this mean for a similar “protocol”? One that has a member attached. (My “strong type-alias” proposal has all such named types derived from an “AnyAlternative” protocol, which derives from “RawRepresentable” and adds another associated type.)
—
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