> 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] >> <mailto:[email protected]>> wrote: >> >>> >>> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev >>>> <[email protected] <mailto:[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 >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> >>> 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? 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. David. > - Doug > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
