[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>
Thorsten Seitz
tseitz42 at icloud.com
Fri May 27 11:28:47 CDT 2016
> Am 27.05.2016 um 17:15 schrieb L Mihalkovic <laurent.mihalkovic at gmail.com>:
>
>
>
>
>> On May 27, 2016, at 4:52 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>
>>>
>>> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> From the point of view of the type system `P & Q` is an anonymous supertype of `P` and `Q`.
>>> This would be just the same if the syntax was `Any<P, Q>`. I don’t see a semantic difference here.
>>>
>>> Whether that is a "container“ or not seems to be an implementation detail to me but should have nothing to do with the type system.
>>> In what way should it be "lossy“?
>
> what is by definition lossy, is the relationship between a type and an existential type that can represent it. Comes from the fact that there is no way to go back to the type we started from once all we hold is the existential (i.e. means it is a one —> n mapping relationship, not a 1 —> 1). Not the notation.
> right?
Right. A protocol with associated types is more like a type family than a type.
protocol P {
associatedtype T
var a: T
func f(_ value: T) -> Int
}
any<P> represents the whole type family with unbound T, i.e. a set of types with one element for each possible value of T
any<P where T: Equatable> represents a subset of the whole type family, i.e. all elements where T conforms to Equatable
any<P where T == Int> represents a concrete type, i.e. one element of the whole type family
So, like you say, the semantics are clear and are independent of the notation.
>
>>>
>>> Am I missing something?
>>
>> I was a bit confused as well and had to read this several times. I think this is talking about a syntactic “container” - i.e. brackets of some kind (as opposed to a “free floating” syntax). I don’t think it is talking about a semantic difference of any kind. But maybe I am still confused an not understanding what was intended...
>
>
> given the semantic we wish to express (combination of conformance declarations), what possible ways do we have to express it. It come down to 2 families of syntax: the ‘container’ form, of which I gave a few examples, versus the non-container form (or free-floating conformance list) of which the straight list is the most obvious, but not the only one.
Ok, so you meant the syntactical form of `any<…>` with "container“. Agreed.
> Joe Groff was reminding us that the second group of syntax also exists.
>
> Compilers love Any<P...Q> , people’s brains love P & Q
Yes, at least mine :-)
-Thorsten
>
>>
>>>
>>> -Thorsten
>>>
>>>
>>>> Am 27.05.2016 um 12:30 schrieb L. Mihalkovic <laurent.mihalkovic at gmail.com <mailto:laurent.mihalkovic at gmail.com>>:
>>>>
>>>> It seem to me we are debating the how of a what that has not been defined. The root question behind all these alternatives seems to be to decide if the existential-ness should be carried by a 'container' that is then refined internally, or derived from the presence of the free-floating refinements. This is the question that splits the possible syntaxes into these 2 groups:
>>>>
>>>> Any<> Any[]
>>>> Type<> Type<>
>
> this was meant to read
> Type<…> Type { …. } Type[ … ]
>
>>>> Existential<>
>>>>
>>>> and the (these are all straw man representations that should not limit the thinking)
>>>>
>>>> P & Q
>>>> @P and @Q
>>>> is P , Q
>>>> P & Q typed
>>>>
>>>> If the answer is to use a 'container' then the next question is to see its relationship to the other existing containers: is it the result of a transformation, is it a superset, or a super type; it is obviously lossy, but not entirely if the solution follows in some of Brent's past suggestion to make some existential types instantiate-able (which opens a very similar problem to what java faced for several years when trying to identify a universal collection literal syntax).
>>>> That will narrow down the field of possible matches... until one syntax emerges as conveying the meaning that is reflected by the answers to each question.
>>>>
>>>> On May 27, 2016, at 10:55 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>>> We could just write
>>>>>
>>>>> let x: P & Q
>>>>> instead of
>>>>> let x: Any<P, Q>
>>>>>
>>>>> let x: Collection where .Element: P
>>>>> instead of
>>>>> let x: Any<Collection where .Element: P>
>>>>>
>>>>> let x: P & Q where P.T == Q.T
>>>>> instead of
>>>>> let x: Any<P, Q where P.T == Q.T>
>>>>>
>>>>> let x: P & Q & R
>>>>> instead of
>>>>> let x: Any<P, Q, R>
>>>>>
>>>>> let x: Collection
>>>>> instead of
>>>>> let x: Any<Collection>
>>>>>
>>>>>
>>>>> This would avoid the confusion of Any<T1, T2> being something completely different than a generic type (i.e. order of T1, T2 does not matter whereas for generic types it is essential).
>>>>>
>>>>>
>>>>> -Thorsten
>>>>>
>>>>>
>>>>>
>>>>>> Am 26.05.2016 um 20:11 schrieb Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>>>>
>>>>>> Something like type<…> was considered at the very start of the whole discussion (in this thread <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html>), but it does not solve the meaning of an existential type and also might lead to even more confusion.
>>>>>>
>>>>>> From my perspective I wouldn’t use parentheses here because it looks more like an init without any label Type.init(…) or Type(…). I could live with Any[…] but this doesn’t look shiny and Swifty to me. Thats only my personal view. ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Adrian Zubarev
>>>>>> Sent with Airmail
>>>>>>
>>>>>> Am 26. Mai 2016 bei 19:48:04, Vladimir.S via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>>>>>>
>>>>>>> Don't think {} is better here, as they also have "established meaning in
>>>>>>> Swift today".
>>>>>>>
>>>>>>> How about just Type(P1 & P2 | P3) - as IMO we can think of such
>>>>>>> construction as "creation" of new type and `P1 & P2 | P3` could be treated
>>>>>>> as parameters to initializer.
>>>>>>>
>>>>>>> func f(t: Type(P1 & P2 | P3)) {..}
>>>>>>>
>>>>>>>
>>>>>>> On 26.05.2016 20:32, L. Mihalkovic via swift-evolution wrote:
>>>>>>> > How about something like Type{P1 & P2 | P3} the point being that "<...>" has an established meaning in Swift today which is not what is expressed in the "<P1,P2,P3>" contained inside Any<P1, P2,P3>.
>>>>>>> >
>>>>>>> >> On May 26, 2016, at 7:11 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>> on Thu May 26 2016, Adrian Zubarev <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> >>>
>>>>>>> >>> There is great feedback going on here. I'd like to consider a few things here:
>>>>>>> >>>
>>>>>>> >>> * What if we name the whole thing `Existential<>` to sort out all
>>>>>>> >>> confusion?
>>>>>>> >>
>>>>>>> >> Some of us believe that “existential” is way too theoretical a word to
>>>>>>> >> force into the official lexicon of Swift. I think “Any<...>” is much
>>>>>>> >> more conceptually accessible.
>>>>>>> >>
>>>>>>> >>>
>>>>>>> >>> This would allow `typealias Any = Existential<>`. * Should
>>>>>>> >>> `protocol A: Any<class>` replace `protocol A: class`? Or at least
>>>>>>> >>> deprecate it. * Do we need `typealias AnyClass = Any<class>` or do we
>>>>>>> >>> want to use any class requirement existential directly? If second, we
>>>>>>> >>> will need to allow direct existential usage on protocols (right now we
>>>>>>> >>> only can use typealiases as a worksround).
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Dave
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> swift-evolution mailing list
>>>>>>> >> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> > _______________________________________________
>>>>>>> > swift-evolution mailing list
>>>>>>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/2301256f/attachment.html>
More information about the swift-evolution
mailing list