<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 24, 2016, at 2:20 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">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></div></blockquote><div><br class=""></div><div>Or maybe you should put it in the future directions section? IMO, it is pretty reasonable to consider the operator syntax to be shorthand, similar to the shorthand for Optional, Array, and Dictionary.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 24, 2016 at 12:07 PM, Joe Groff via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class="">
<br class="">
+ Infix notation works not only in type position, but constraint position as well, providing a nicer way to express multiple type variable constraints:<br class="">
var x: P && Q<br class="">
func foo<T: P && Q, U>(x: T)<br class="">
<br class="">
+ Infix notation feels subjectively lighter, being less nesty and angle-bracket-blinding. Compare the above with:<br class="">
var x: Any<P, Q><br class="">
func foo<T: Any<P,Q>, U>(x: T)<br class="">
<br class="">
Particularly in the second declaration, I find the nested angle brackets and comma delimiters to be hard to visually parse.<br class="">
<br class="">
± 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 class="">
<br class="">
- 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 class="">
<br class="">
func sum(_ collection: Any<Sequence where Element == Int>) -> Int { ... }<br class="">
<br class="">
(though this notation still feels heavy and awkward to me).<br class="">
<br class="">
- 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 class="">
<br class="">
func staticType<T>(of _: T) -> T.Type { return T.self }<br class="">
<br class="">
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 class="">
<br class="">
- 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 class="">
<br class="">
// Let's say 'protocol' constraints indicate second-order constraint variables:<br class="">
enum Any<Constraints: protocol> {<br class="">
// And we have GADTs:<br class="">
case value<T: Constraints>(T)<br class="">
}<br class="">
<br class="">
// And we have user-defined value subtyping:<br class="">
extension <Constraints: protocol, T: Constraints> T: Any<Constraints> { ... }<br class="">
<br class="">
-Joe<br class="">
<div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>