<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 20, 2016, at 2:07 PM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I actually like "any&lt;P1, P2&gt;". It does provide that very distinctive visual signal that any&lt;&gt; is not a generic type, and that 'any' is not itself a type, but rather a special keyword for constructing an existential:</div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Array&lt;Int&gt; &nbsp;// a generic type, Array, containing integers</div><div class="">any&lt;P1, P2&gt; // a protocol composition of two protocols</div><div class=""><br class=""></div><div class="">In this case, would we want to support "any&lt;&gt;" in addition to Any? The parsing issues should go away, since these are two different identifiers.</div></div></div></blockquote><div><br class=""></div><div>Isn’t `Any` a typealias for `any&lt;&gt;`? &nbsp;If so, we have to support `any&lt;&gt;`! :)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 20, 2016 at 12:04 PM, Matthew Johnson <span dir="ltr" class="">&lt;<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div dir="ltr" class="">I think you should submit this for review, but I also think you should take the part of your older proposal to add class support to Any&lt;...&gt; and submit it as a separate proposal. (I mean, the part where you can define things like "Any&lt;UIViewController, Protocol&gt;" or "Any&lt;class, Protocol&gt;".)<div class=""><br class=""></div><div class="">Yes, it is additive, but even getting that feature into Swift 3 would be an enormous benefit if it can be implemented easily. And the core team is probably better positioned than anyone else to determine whether that's true.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Austin, what is your thought on switching to `any` rather than `Any` since it does not behave like a user-defined generic type?&nbsp; The convention is for types to be uppercase and keywords to be lowercase.&nbsp; This falls more into the category of a keyword and has its own behavior distinct from the behavior of all generic types.&nbsp; Making it stand out syntactically will help to make that clear.</div><div class=""><div class="h5"><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 Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div></div><div class=""><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">This is a follow up proposal to&nbsp;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md" target="_blank" class=""><span class="">SE-0095</span></a>&nbsp;which should be considered for Swift 3 if SE-0095 will be accepted.</div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">Here is the formatted draft: <a href="https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md" target="_blank" class="">https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md</a></div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">Please provide your feedback in this thread, and don’t make a race who is making a better proposal on the exact same topic.</div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">If you spot any types or other mistakes I’d be happy to see you pointing me to them. ;)</div><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><div class=""><div style="font-family:helvetica,arial;font-size:13px" class="">--&nbsp;<br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div></div><div class=""><div class=""><br class=""></div>

<h1 class="">Disallow redundant <code class="">Any&lt;...&gt;</code> constructs</h1>

<ul class="">
<li class="">Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md" target="_blank" class="">SE-NNNN</a></li>
<li class="">Author: <a href="https://github.com/DevAndArtist" target="_blank" class="">Adrian Zubarev</a></li>
<li class="">Status: <a class="">Awaiting review</a></li>
<li class="">Review manager: TBD</li>
</ul>

<h2 class="">Introduction</h2><p class="">This is a follow up proposal to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md" target="_blank" class="">SE–0095</a>, if it will be accepted for Swift 3. The current concept of <code class="">Any&lt;...&gt;</code> introduced in SE–0095 will allow creation of redundant types like <code class="">Any&lt;A&gt; == A</code>. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.</p><p class="">Swift-evolution thread: <a class="">[Proposal] Disallow redundant <code class="">Any&lt;...&gt;</code> constructs</a></p>

<h2 class="">Motivation</h2><p class="">If SE–0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be <strong class="">Any-type requirement</strong> (where <em class="">type</em> could be <code class="">class</code>, <code class="">struct</code> or <code class="">enum</code>) and <strong class="">Class requirement</strong>. Without any restrictions these will introduce more redundancy. </p><p class="">As said before it is possible to create redundant types like <code class="">Any&lt;A&gt; == A</code> or endless shadowed redundant nesting:</p>

<pre class=""><code class="">typealias A_1 = Any&lt;A&gt;
typealias A_2 = Any&lt;A_1&gt;
typealias A_3 = Any&lt;A_2&gt;
/* and so on */
</code></pre><p class="">This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won’t introduce any breaking changes for <code class="">Any&lt;...&gt;</code> existential.</p>

<h2 class="">Proposed solution</h2>

<ol class="">
<li class=""><p class="">If empty <code class="">Any&lt;&gt;</code> won’t be disallowed in SE–0095, we should disallow nesting empty <code class="">Any&lt;&gt;</code> inside of <code class="">Any&lt;...&gt;</code>.</p></li>
<li class=""><p class="">Disallow nesting <code class="">Any</code> (type refers to current <code class="">typealias Any = protocol&lt;&gt;</code>) inside of <code class="">Any&lt;...&gt;</code>.</p></li>
<li class=""><p class="">Disallow <code class="">Any&lt;...&gt;</code> containing a single <code class="">Type</code> like <code class="">Any&lt;Type&gt;</code>.</p><p class="">The first three rules will ban constructs like <code class="">Any&lt;Any&lt;&gt;, Type&gt;</code> or <code class="">Any&lt;Any, Type&gt;</code> and force the developer to use <code class="">Type</code> instead.</p></li>
<li class="">Disallow nesting a single <code class="">Any&lt;...&gt;</code> inside another <code class="">Any&lt;...&gt;</code>.

<ul class="">
<li class="">e.g. <code class="">Any&lt;Any&lt;FirstType, SecondType&gt;&gt;</code></li>
</ul></li>
<li class=""><p class="">Disallow same type usage like <code class="">Any&lt;A, A&gt;</code> or <code class="">Any&lt;A, B, A&gt;</code> and force the developer to use <code class="">A</code> or <code class="">Any&lt;A, B&gt;</code> if <code class="">A</code> and <code class="">B</code> are distinct.</p></li>
<li class=""><p class="">Disallow forming redundant types when the provided constraints are not independent.</p>

<pre class=""><code class="">// Right now `type` can only be `protocol` but in the future Any&lt;...&gt;  
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}  
     
// all following types are equivalent to `A`
Any&lt;A, Any&lt;B, C&gt;&gt;
Any&lt;Any&lt;A, B&gt;, C&gt;
Any&lt;Any&lt;A, C&gt;, B&gt;
Any&lt;A, B, C&gt;
Any&lt;A, B&gt;
Any&lt;A, C&gt;
</code></pre>

<ul class="">
<li class=""><p class="">If all contraints form a known <code class="">Type</code> provide a <code class="">Fix-it</code> error depending on the current context. If there is more than one <code class="">Type</code>, provide all alternatives to the developer.</p></li>
<li class=""><p class="">Using <code class="">Any&lt;...&gt;</code> in a generic context might not produce a <code class="">Fix-it</code> error:</p>

<pre class=""><code class="">protocol A {}
protocol B {}
protocol C: A, B {}
         
// there is no need for `Fix-it` in such a context
func foo&lt;T: Any&lt;A, B&gt;&gt;(value: T) {}
</code></pre></li>
</ul></li>
</ol>

<h2 class="">Impact on existing code</h2><p class="">These changes will break existing code. Projects abusing <code class="">Any&lt;...&gt;</code> to create redundant types should be reconsidered of usings the equivalent <code class="">Type</code> the compiler would infer. One would be forced to use <code class="">A</code> instead of <code class="">Any&lt;A&gt;</code> for example. A <code class="">Fix-it</code> error message can help the developer to migrate his project.</p>

<h2 class="">Alternatives considered</h2>

<ul class="">
<li class="">Leave redundancy as-is for Swift 3 and live with it.</li>
<li class="">Deprecate redundancy in a future version of Swift, which will introduce breaking changes.</li></ul></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>