> On Feb 6, 2017, at 11:30 AM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> On Feb 5, 2017, at 3:20 PM, David Hart <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. > > Tricky business; you have a proposal that’s very likely to get universal > support (adding class constraints to existentials) and one that’s likely to > be controversial (changing existential syntax away from what we just adopted > in Swift 3). My inclination is to separate the two, because I worry that the > first proposal could get swallowed up in the discussion of the second… and it > gets more messy if we have to detangle one proposal into two after running > the review.
+1 > > - Doug > >> >> David >> >> On 3 Feb 2017, at 18:12, Douglas Gregor <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>>> On Feb 2, 2017, at 3:24 PM, David Hart <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution >>>>> <[email protected] <mailto:[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? >>> >>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
