Btw, in case we have `where` keyword in syntax related to types/protocols
(when defining constrains. and not some symbol like '>>'.. don't know, for
example), why we can't have 'and' keyword also when discuss the syntax of
type/protocol conjunction?
I.e.
let x: P and Q
let x: P and Q where P.T == Q.T
let x: P and Q and R
or, for consistency, as I understand it, we should have
let x: P & Q >> P.T == Q.T
On 27.05.2016 11:55, Thorsten Seitz via swift-evolution 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
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> 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
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
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
