<div dir="ltr">I agree with Dave. To me, building in a limit so that the return type can't be inferred seems arbitrary.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 15, 2017 at 12:41 AM, Dave Abrahams 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"><span class=""><br>
on Fri Jan 13 2017, John McCall <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> I'm also not sure we'd ever want the element type to be inferred from<br>
> context like this. Generic subscripts as I see it are about being<br>
> generic over *indexes*, not somehow about presenting a polymorphic<br>
> value.<br>
<br>
</span>Actually I *would* want to be able to do that, though I admit it's the<br>
1% case (or less).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Chris Eidhof</div>
</div>