> On 3 Feb 2017, at 18:12, Douglas Gregor via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>>
>> On Feb 2, 2017, at 3:24 PM, David Hart <da...@hartbit.com
>> <mailto:da...@hartbit.com>> wrote:
>>
>>>
>>> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
>>>> On Feb 2, 2017, at 2:54 PM, David Smith <david_sm...@apple.com
>>>> <mailto:david_sm...@apple.com>> wrote:
>>>>
>>>>>
>>>>> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>>
>>>>>> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev
>>>>>> <adrian.zuba...@devandartist.com
>>>>>> <mailto:adrian.zuba...@devandartist.com>> 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
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
I think the current syntax is okay. I’ve been thinking about existentials as
part of the proposal on eliminating protocol nesting
(https://github.com/apple/swift-evolution/pull/552
<https://github.com/apple/swift-evolution/pull/552>).
On the one hand, the Any<...> syntax reads very nicely because it literally
tells you that it’s “any type conforming to this bunch of constraints” and
gives you a clear visual bookend for the constraint list.
On the other hand, the “&” syntax is much easier to read.
var myCollection: Any<UIView where Self: Collection, Iterator.Element ==
String> = something
vs
var myCollection: UIView & Collection where Iterator.Element == String =
something
maybe we could just use brackets, though…
var myCollection: (UIView & Collection where Iterator.Element == String) =
something
Or maybe allow lone angle-brackets when writing existentials, for an even
bigger visual distinction (I like this):
var myCollection: <UIView & Collection where Iterator.Element == String> =
something
- Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
