As they are heavily linked, should a change like this be included in the superclass + class proposal or separately?
I'm heavily tending towards (1), and redefining: typealias Any = Any<> typealias AnyObject = Any<class> Does that sound reasonable to you? Just checking before I rewrite this proposal sometime in the next couple of days. David > On 3 Feb 2017, at 18:12, Douglas Gregor <[email protected]> wrote: > > >>> On Feb 2, 2017, at 3:24 PM, David Hart <[email protected]> wrote: >>> >>> >>>> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>>> On Feb 2, 2017, at 2:54 PM, David Smith <[email protected]> wrote: >>>>> >>>>> >>>>>> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev >>>>>> <[email protected]> wrote: >>>>>> >>>>>> typealias AnyObject = … is nice to have, but how about if we fully drop >>>>>> the class constraint-keyword and generalize AnyObject instead? >>>>>> >>>>> That’s a good point. My *technical* goal is for AnyObject to cease to be >>>>> a protocol, because it’s really describing something more fundamental >>>>> (“it’s a class!”). Whether we spell that constraint as “class” or >>>>> “AnyObject” doesn’t affect that technical goal. >>>>> >>>>> I’d gravitated toward the “class” spelling because the idea of a class >>>>> constraint seems most naturally described by “class”, and it’s >>>>> precedented in C#. >>>>> >>>>> However, the changes in SE-0095 to make “Any” a more fundamental type >>>>> (and not just a typealias) definitely open the door to doing the same >>>>> thing with “AnyObject”—just make it a built-in notion in the language, >>>>> and the spelling for a class constraint. It *certainly* works better with >>>>> existentials. >>>>> >>>>>> In the future we might want to add AnyValue with value (semantics) >>>>>> constraint, would that mean that we’d need another keyword there like >>>>>> value? >>>>>> >>>>> “value” would be a terrible keyword, as you know. Point taken :) >>>>> >>>>> If we did something like this, we would probably want it to be akin to >>>>> ValueSemantics—not just “it’s a struct or enum”, but “it provides value >>>>> semantics”, because not all structs/enums provide value semantics (but >>>>> immutable classes do). >>>>> >>>>>> Speaking of the future directions: >>>>>> >>>>>> Now that we’re no longer supporting the idea of Any<…> syntax and any >>>>>> type prefixed with Any seems to be special for its particular usage, >>>>>> could we safely bring the empty Any protocol back (is this somehow ABI >>>>>> related?)? >>>>>> >>>>> From an implementation standpoint, the choice to make AnyObject a magic >>>>> protocol was a *horrible* decision. We have hacks throughout >>>>> everything—the compiler, optimizers, runtime, and so on—that specifically >>>>> check for the magic AnyObject protocol. So, rather than make Any a magic >>>>> protocol, we need to make AnyObject *not* magic. >>>>> >>>>>> One day after this proposal is accepted, implemented and released, we >>>>>> probably will talk about the where clause for existentials. But since a >>>>>> lot of the existentials will have the form typealias Abc = …, this talk >>>>>> will also include the ability to constrain generic typealiases. >>>>>> >>>>> By “one day” I suspect you mean “some day” rather than “the day after” :) >>>>> >>>>> Yes, I feel like this is a natural direction for existentials to go. >>>> >>>> Looking ahead to when this is on the table, I'm a little worried about the >>>> syntactic implications of constrained existentials now that the Any<> >>>> syntax doesn't seem to be as popular. The obvious way to go would be >>>> >>>> 'X & Y where …' >>>> >>>> But that leads to ambiguity in function declarations >>>> >>>> func doTheThing<T>() -> X & Y where … where T == … >>>> >>>> This could be resolved by requiring constrained existentials to be >>>> typealiased to return them, but I don't think there's any other situations >>>> where we require a typealias to use something, and it just feels like a >>>> workaround. >>> >>> Types can be parenthesized, so that’s a workaround. But I too have some >>> concerns here that we’re creating an ambiguity that users will trip over. >> >> On top of the ambiguity, I’m really sad that we dropped the Any<A, B, C> >> syntax because we lost the parallel to inheritance clauses which use the >> comma as separating character. They both represent similar concepts: a type >> inheriting and conforming and an existential represent all types which >> inherit and conform. >> >> I’ve got to ask, is there any chance that either of the two could happen: >> >> 1) Bring back the Any<A, B, C> syntax instead of A & B & C? >> 2) Replace the inheritance clause X : A, B, C to X : A & B & C? > > Both are possible, as is > > (3) Let A & B & C be a shortcut syntax for Any<A, B, C>, such that Any<…> is > the more general version that also permits where clauses, “class” > constraints, etc. > > Note that (2) would kill me ;) > >> I know that both are severely source-breaking changes, but either of those >> would simplify the language by using the same syntax for two very similar >> concepts. Plus, number 1 would allow us to disambiguate function >> declarations. I know many people would rejoice having Any<> back. > > Yes, they’re both significant source breakage. It’s source breakage of the > “easy” kind, which only affects parsing and therefore makes it easy to keep > supporting the Swift 3 syntax in Swift 4. > > (3), on the other hand, isn’t a simplification at all… it’s admitting > redundant syntax to avoid source breakage. > > - Doug > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
