> On Feb 5, 2017, at 3:20 PM, David Hart <[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.
- 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
