<div dir="ltr">I actually consider the angle brackets to be easier to read, because it's visually easy to pair the starting "<" with the ending ">" and mentally delineate the entire extent of the declaration. (I suspect I may be alone in this, though :).<div><br></div><div>If we can come up with reasonable strawman syntax for adding constraints, we should probably throw this idea into the mix. I meant to ask you earlier, but forgot. I would be happy to submit a PR to add it to the alternatives section, though, so it can be formally reviewed, discussed, and considered.</div><div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 12:07 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">'Any' is definitely a better name, but I think this is still syntax only a compiler can love. If we're going to repaint this bikeshed, I think we should also consider as an alternative some form of infix syntax for composing constraints. Rust uses `P1 + P2`, and various C++ proposals have suggested `P1 && P2`. Some pros(+) and cons(-) I can see with this approach:<br>
<br>
+ Infix notation works not only in type position, but constraint position as well, providing a nicer way to express multiple type variable constraints:<br>
var x: P && Q<br>
func foo<T: P && Q, U>(x: T)<br>
<br>
+ Infix notation feels subjectively lighter, being less nesty and angle-bracket-blinding. Compare the above with:<br>
var x: Any<P, Q><br>
func foo<T: Any<P,Q>, U>(x: T)<br>
<br>
Particularly in the second declaration, I find the nested angle brackets and comma delimiters to be hard to visually parse.<br>
<br>
± Like 'Any', an infix operator doesn't pass judgment on what kinds of constraint is being applied, so it naturally extends to expressing class-with-protocol constraints.<br>
<br>
- Infix notation doesn't provide an obvious place for generalized existentials to hang secondary constraints. The angle brackets for Any provide an enclosed syntactic space we can easily stuff a 'where' clause:<br>
<br>
func sum(_ collection: Any<Sequence where Element == Int>) -> Int { ... }<br>
<br>
(though this notation still feels heavy and awkward to me).<br>
<br>
- The bracketing of `Any` might let us address the curious case of protocol vs existential metatypes in a better way. Right now, the static metatype for a protocol type (the type of `P.self`) is spelled `P.Protocol`, and the dynamic metatype for any type conforming to the protocol (the erased type of `T.self` where T: P) is spelled `P.Type`. Unintuitively, when a protocol type is substituted into `T.Type` in a generic context, you get the static type `P.Protocol` rather than `P.Type`, for soundness reasons:<br>
<br>
func staticType<T>(of _: T) -> T.Type { return T.self }<br>
<br>
This substitution behavior could be made clearer if we moved a dynamic metatype's `.Type` into the Any brackets, so that `Any<P.Type>` would be the dynamic metatype of any type conforming to P, and `Any<P>.Type` would be the static metatype of the type `Any<P>`. Infix notation doesn't provide an opportunity to make this clarification.<br>
<br>
- A few people have also noted the similarity between Any<...> and normal generic types. This is potentially confusing today, but with enough magic language features from the future, Any *could* conceivably be made a library feature in the fullness of time:<br>
<br>
// Let's say 'protocol' constraints indicate second-order constraint variables:<br>
enum Any<Constraints: protocol> {<br>
// And we have GADTs:<br>
case value<T: Constraints>(T)<br>
}<br>
<br>
// And we have user-defined value subtyping:<br>
extension <Constraints: protocol, T: Constraints> T: Any<Constraints> { ... }<br>
<br>
-Joe<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>