Btw, if we'd have separate class<> and struct<> - we'd be able to have
method to separate reference type from value type.
We can write now : print(c is protocol<>)
and we'd can:
print(c is class<>)
print(c is struct<>)
Just thoughts..
On 13.05.2016 20:04, Vladimir.S wrote:
On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:
Why would you want to add all of these different formats where only one
could serve them all. This is redundant in my opinion.
`struct<>` and `enum<>` would have same rules, only the first element would
be a different value-type. I might consider this as an alternative.
Actually, I fully support your idea and strongly +1 for `type<>` keyword. I
don't believe it will confuse anyone as protocol<> does not confuse currently.
But as I can see, the community(or core team) is strongly against of using
`type` keyword.
So, we have situation : protocol<> and .. all<> ? Will all<> include
protocols also? Probably I'd support to remove protocol<> and introduce
just all<> for all :-) But if we have protocol<> and can't have type<> - I
asked why we can't for clarity and consistency have class<> struct<>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
