> Am 27.05.2016 um 17:15 schrieb L Mihalkovic <[email protected]>:
>
>
>
>
>> On May 27, 2016, at 4:52 PM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>>:
>>>>
>>>> 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
>>>> <[email protected] <mailto:[email protected]>> 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
>>>>>> <[email protected] <mailto:[email protected]>>:
>>>>>>
>>>>>> 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
>>>>>> ([email protected] <mailto:[email protected]>) 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
>>>>>>> >> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>> on Thu May 26 2016, Adrian Zubarev <[email protected]
>>>>>>> >>> <mailto:[email protected]>> 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
>>>>>>> >> [email protected] <mailto:[email protected]>
>>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> > _______________________________________________
>>>>>>> > swift-evolution mailing list
>>>>>>> > [email protected] <mailto:[email protected]>
>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
