I guess you don’t understand that a so called proposal should have enough
details to explain the proposed behavior to someone who is not the author of
the proposal. You’re offering is fine but a few unexplained lines of your gist
wouldn’t make through a proposal review at all. I rather give a book to someone
to read then a few unexplained samples where you’d scratch your head trying to
figure out what my intention might mean. I’m sure you learned math theories not
by looking at complex formulas without reading any explanation about what its
parameter and mathematical-syntax mean, if you ever did. I’m not trying to
insult here anyone so don’t take that to personal!
That said, I’m strongly against that ugly and not swifty looking _[ ] syntax.
ClassName[Params] is okay but an empty _[ ] is just ugly. Again this is my
personal opinion and it’s up to the core team to decide.
If we’d look at your so called ‘absurd’ example and imagine the shorthand
syntax support class-requirements like proposed:
let v: UIViewController & UIWindow & UITableViewDelegate
there is definitely one thing that should happen for sure:
complier should raise an error at compile time right after typing out the whole
existential type or even after UIViewController & UIWindow.
such an error message would provide enough informations for you that an
existential type with class requirements cannot be composed with two classes
(without nesting existentials)
Lets try nesting:
let v: UIViewController & (UIWindow & UITableViewDelegate)
this will again raise an error and tell you that UIViewController and UIWindow
has no subtyping-relationship and are incompatible class types.
If you tried creating an existential type without reading and learning from
docs first, lets say it’s your own fault that you will end up with these error
messages, but either way you’d quickly learn how they behave.
That said, merging types to existentials with an infix & operator does look
swifty to me (my opinion again) and is intuitive enough for that behavior.
You may ask for | operator, but this is a different story here. I’d support it
to be able reduce overloading:
func foo(value: OneOf<A, B, C>) { … }
func foo(value: A | B | C) { … }
// Imagine AnyStruct and AnyEnum (they probably won't make it into Swift)
typealias AnyValue = AnyStruct | AnyEnum
// almost `Any`, we miss tuples and closures/functions here
typealias AnyExtendible = AnyValue | AnyObject
--
Adrian Zubarev
Sent with Airmail
Am 15. Juni 2016 um 06:27:19, L. Mihalkovic ([email protected])
schrieb:
You need 3 long paragraph to explain it, the alternative I offer requires none.
https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051
Regards
(From mobile)
On Jun 14, 2016, at 11:44 PM, Adrian Zubarev via swift-evolution
<[email protected]> wrote:
One more thing for clarity:
Any-class requirement: This must be the first requirement, if present. This
requirement consists of the keyword class, and requires the existential to be
of any class type.
Class requirement: This must be the first requirement, if present. This
requirement consists of the name of a class type, and requires the existential
to be of a specific class or its subclasses. There can be only one class name
constraint, and it is mutually exclusive with the any-class requirement.
Nested any<...>: This requirement consists of another any<...> construct.
--
Adrian Zubarev
Sent with Airmail
Am 14. Juni 2016 um 23:42:00, Adrian Zubarev ([email protected])
schrieb:
Which addresses the fact that nons of the proposals so far truly prevent
absurde declarations like:
Let v: Any< UIViewController, UIWindow, UITableViewDelegate>
Let v: UIViewController & UIWindow & UITableViewDelegate
_______________________________________________
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
