<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">+1 for this as the original post suggested already `type<…>` or `all<…>`. `any<…>` is fine here.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Wrong thread though. :D</div> <br> <div id="bloop_sign_1463771295199070976" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 20. Mai 2016 bei 21:07:20, Austin Zheng (<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">I actually like "any<P1, P2>". It does provide
that very distinctive visual signal that any<> is not a
generic type, and that 'any' is not itself a type, but rather a
special keyword for constructing an existential:
<div><br></div>
<div>Array<Int> // a generic type, Array, containing
integers</div>
<div>any<P1, P2> // a protocol composition of two
protocols</div>
<div><br></div>
<div>In this case, would we want to support "any<>" in
addition to Any? The parsing issues should go away, since these are
two different identifiers.</div>
<div><br></div>
<div>Austin</div>
<div><br></div>
<div><br></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 20, 2016 at 12:04 PM, Matthew
Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div>
<blockquote type="cite">
<div><span class="">On May 20, 2016, at 2:00 PM, Austin Zheng via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:</span></div>
<span class=""><br></span>
<div>
<div dir="ltr"><span 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<...> and submit it as a
separate proposal. (I mean, the part where you can define things
like "Any<UIViewController, Protocol>" or "Any<class,
Protocol>".)</span>
<div><span class=""><br></span></div>
<div><span 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.</span></div>
</div>
</div>
</blockquote>
<div><span class=""><br></span></div>
<div>Austin, what is your thought on switching to `any` rather than
`Any` since it does not behave like a user-defined generic
type? The convention is for types to be uppercase and
keywords to be lowercase. This falls more into the category
of a keyword and has its own behavior distinct from the behavior of
all generic types. Making it stand out syntactically will
help to make that clear.</div>
<div>
<div class="h5"><br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><br></div>
<div>Austin</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 20, 2016 at 2:39 AM, Adrian
Zubarev 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">
<div style="word-wrap:break-word">
<div>
<div><br></div>
</div>
<div>
<div style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
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"><span>SE-0095</span></a> 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">
<br></div>
<div style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
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">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">
<br></div>
<div style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
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">
<br></div>
<div style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
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">
<br></div>
<div>
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
</div>
<div>
<div><br></div>
<h1>Disallow redundant <code>Any<...></code> constructs</h1>
<ul>
<li>Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md" target="_blank">SE-NNNN</a></li>
<li>Author: <a href="https://github.com/DevAndArtist" target="_blank">Adrian Zubarev</a></li>
<li>Status: <a>Awaiting review</a></li>
<li>Review manager: TBD</li>
</ul>
<h2>Introduction</h2>
<p>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">SE–0095</a>, if it will be accepted for Swift 3.
The current concept of <code>Any<...></code> introduced in
SE–0095 will allow creation of redundant types like
<code>Any<A> == A</code>. I propose to disallow such
redundancy in Swift 3 to prevent breaking changes in a future
version of Swift.</p>
<p>Swift-evolution thread: <a>[Proposal] Disallow redundant
<code>Any<...></code> constructs</a></p>
<h2>Motivation</h2>
<p>If SE–0095 will be accepted there will be future proposals to
enhance its capabilities. Two of these will be <strong>Any-type
requirement</strong> (where <em>type</em> could be
<code>class</code>, <code>struct</code> or <code>enum</code>) and
<strong>Class requirement</strong>. Without any restrictions these
will introduce more redundancy.</p>
<p>As said before it is possible to create redundant types like
<code>Any<A> == A</code> or endless shadowed redundant
nesting:</p>
<pre><code>typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */
</code>
</pre>
<p>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>Any<...></code>
existential.</p>
<h2>Proposed solution</h2>
<ol>
<li>
<p>If empty <code>Any<></code> won’t be disallowed in
SE–0095, we should disallow nesting empty <code>Any<></code>
inside of <code>Any<...></code>.</p>
</li>
<li>
<p>Disallow nesting <code>Any</code> (type refers to current
<code>typealias Any = protocol<></code>) inside of
<code>Any<...></code>.</p>
</li>
<li>
<p>Disallow <code>Any<...></code> containing a single
<code>Type</code> like <code>Any<Type></code>.</p>
<p>The first three rules will ban constructs like
<code>Any<Any<>, Type></code> or <code>Any<Any,
Type></code> and force the developer to use <code>Type</code>
instead.</p>
</li>
<li>Disallow nesting a single <code>Any<...></code> inside
another <code>Any<...></code>.
<ul>
<li>e.g. <code>Any<Any<FirstType,
SecondType>></code></li>
</ul>
</li>
<li>
<p>Disallow same type usage like <code>Any<A, A></code> or
<code>Any<A, B, A></code> and force the developer to use
<code>A</code> or <code>Any<A, B></code> if <code>A</code>
and <code>B</code> are distinct.</p>
</li>
<li>
<p>Disallow forming redundant types when the provided constraints
are not independent.</p>
<pre><code>// Right now `type` can only be `protocol` but in the future Any<...>
// 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<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>
</code>
</pre>
<ul>
<li>
<p>If all contraints form a known <code>Type</code> provide a
<code>Fix-it</code> error depending on the current context. If
there is more than one <code>Type</code>, provide all alternatives
to the developer.</p>
</li>
<li>
<p>Using <code>Any<...></code> in a generic context might not
produce a <code>Fix-it</code> error:</p>
<pre><code>protocol A {}
protocol B {}
protocol C: A, B {}
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}
</code>
</pre></li>
</ul>
</li>
</ol>
<h2>Impact on existing code</h2>
<p>These changes will break existing code. Projects abusing
<code>Any<...></code> to create redundant types should be
reconsidered of usings the equivalent <code>Type</code> the
compiler would infer. One would be forced to use <code>A</code>
instead of <code>Any<A></code> for example. A
<code>Fix-it</code> error message can help the developer to migrate
his project.</p>
<h2>Alternatives considered</h2>
<ul>
<li>Leave redundancy as-is for Swift 3 and live with it.</li>
<li>Deprecate redundancy in a future version of Swift, which will
introduce breaking changes.</li>
</ul>
</div>
</div>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
<br></blockquote>
</div>
<br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div>
</blockquote>
</div>
</div>
</div>
<br></div>
</blockquote>
</div>
<br></div>
</div></div></span></blockquote></body></html>