For me requiring parentheses for this 'feature' will confuse in most cases
as looks similar to tuple definition:
let x : (Int, String, Bool) = oneThing
let y : (MyProto & Hashable) = anotherThing
but below looks IMO more clean and I instantly(don't need to parse first
open parenthesis) see that this is a 'conjunction' of protocols not tuple :
let y : MyProto & Hashable = anotherThing
Bur +1 for optional parentheses
On 27.05.2016 19:36, Austin Zheng via swift-evolution wrote:
I think the parentheses are the fundamental aspect of the suggestion :).
Let me turn the question around. If tuples were declared like this:
let myTuple : Int, String, Bool = (10, "hello", false)
would the type be more or less readable? I find it a lot more difficult to
immediately parse than:
let myTuple : (Int, String, Bool) = (10, "hello", false)
At the same time, nobody's complained about tuple type parentheses getting
in the way.
We're trying to establish a syntax that will hopefully be used for things
significantly more complicated than tuple definitions, which are just a
list of types. I think readability is a major concern. Typealiases should
be supported, but they shouldn't be required to make the feature useable.
Finally, wouldn't we need some delimiter for nested existential definitions
anyways? Now you have the confusing situation where the outside definition
has no delimiters, but the inside ones do:
// Why does the inner existential look fundamentally different than the
outer one?
// Not to mention, visually parsing the boundaries of this type when you
look at it in a function signature
let x : Protocol1, Protocol2, (Protocol 3 where .Foo == Int) where
Protocol2.Bar : Baz
I hope that explains my reasoning.
Best,
Austin
On May 27, 2016, at 9:28 AM, Matthew Johnson <[email protected]
<mailto:[email protected]>> wrote:
Sent from my iPad
On May 27, 2016, at 11:18 AM, Austin Zheng <[email protected]
<mailto:[email protected]>> wrote:
Here's a strawman idea.
What if we go with '&' and 'where', but we enclose the whole thing in
parentheses?
(class & Protocol1 & Protocol2 where .Foo == Int, .Bar : Baz)
There are a couple of reasons I propose this syntax:
- It makes it very clear where the definition of the type begins and
ends. I understand people really despise angle brackets, but I really
want some way to visually delineate the boundaries of the type. Plus, I
imagine it makes syntax a little easier to parse and preemptively
forbids some ambiguities.
- It's a structural, not nominal, type, like a tuple, so it uses parens
as well. This reserves "<" and ">" for generic types.
- The '&' is easily understood - "Protocol1" *and* "Protocol2". It's
also a signal that order doesn't matter - just like how order matters
with things that use commas, like argument lists, tuples, and array
members, order doesn't generally matter with bitwise or logical 'and'
operators.
- If we ever decide to have union types, we have a very elegant third
form of nominal type syntax that naturally falls out: (MyClass1 |
MyClass2 | MyClass3).
Thoughts?
Generally in favor. But I would not require the parentheses. I believe
they would be allowed optionally automatically, just as (Int) is the same
as Int (because single element tuples don't exist and the underlying type
is used directly instead). It seems better to leave parentheses up to a
matter of style.
Austin
On May 27, 2016, at 9:07 AM, Thorsten Seitz via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Am 27.05.2016 um 16:54 schrieb Matthew Johnson <[email protected]
<mailto:[email protected]>>:
On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Personally I think `&` is more lightweight (and it is established in
other languages like Ceylon and Typescript) and `where` is more
expressive (and established in Swift for introducing constraints), so
I would stay with these.
I agree. If we can make `&` with `where` work syntactically it would
be nice to go in this lighter weight direction. If we decide to do
that the question then becomes what to do with `protocol`. Would it
be feasible to replace it with `&` in Swift 3 if we decide on that
direction?
Yep. `protocol` should be replaced with `&` in that case.
-Thorsten
-Thorsten
Am 27.05.2016 um 14:34 schrieb Vladimir.S <[email protected]
<mailto:[email protected]>>:
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]> <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]> <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]> <mailto:[email protected]>>
wrote:
>>
>>
>>> on Thu May 26 2016, Adrian Zubarev <[email protected]
<mailto:[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]> <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> [email protected]
<mailto:[email protected]> <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
<mailto:[email protected]> <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
<mailto:[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
