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]> wrote:
on Thu May 26 2016, Adrian Zubarev <[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]
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
