<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 Jan 12, 2017, at 9:56 AM, Gwendal Roué 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello Chris, thanks for this draft!<div class=""><br class=""></div><div class="">May I suggest that the introduction mentions genericity on return type as well?</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class=""> subscript</span><span style="font-variant-ligatures: no-common-ligatures" class=""><T>(</span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">_</span><span style="font-variant-ligatures: no-common-ligatures" class=""> index: Int) -> T</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">(I have database rows in mind.)</span></div></div></div></div></blockquote><div><br class=""></div>Yeah, there’s no reason to restrict it to either just the index or element type.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Gwendal</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><blockquote type="cite" class=""><div class="">Le 12 janv. 2017 à 18:53, Chris Eidhof via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Ok, I've got a draft up as a gist: <a href="https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25" class="">https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25</a><div class=""><br class=""></div><div class="">Before I submit it, could someone let me know if adding generics to subscripts would influence the ABI? ( still feel pretty clueless in that area).</div><div class=""><br class=""></div><div class="">Thanks!</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor 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"><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPhone</div><span class=""><div class=""><br class="">On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Okay,<div class=""><br class=""></div><div class="">I agree that throwing subscripts would be great to have. Likewise, generic(and maybe even throwing) properties could be useful. However, I think that for this proposal, it makes more sense to focus on just generic subscripts, and mention throwing subscripts as "future improvements"? </div></div></div></blockquote><div class=""><br class=""></div></span>There's already a draft proposal covering throwing subscripts. You can mention it's existence, but I don't see a reason to say much. <div class=""><br class=""></div><div class=""> - Doug</div><div class=""><div class="h5"><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 11, 2017 at 8:52 PM, John McCall 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"><div style="word-wrap:break-word" class=""><span class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><blockquote type="cite" class=""><div class="">On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7479585401879917020m_-6348449611380270962Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class="">On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7479585401879917020m_-6348449611380270962Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><div class="">[Forgot to CC swift-evolution the first time]</div><div class=""><br class=""></div><div class=""><div class="">When this came up last, it was seen as more so a bug in the current implementation, rather than an explicit choice. There's no need for a proposal, just a JIRA: <a href="https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22" target="_blank" class="">https://bugs.swift.org/b<wbr class="">rowse/SR-115?jql=text%20~%20%2<wbr class="">2Generic%20subscript%22</a> </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">It’s a nontrivial new user-facing feature with new syntax in the language, so it’ll need a proposal. ‘twould be good for the proposal to link to the JIRA ticket.</div><div class=""><br class=""></div><div class="">I’ve only heard positive reactions toward this feature, and it’s something that the standard library could make good use of.</div></div></div></div></blockquote><br class=""></div><div class="">+1, this would be clearly great to happen.</div><div class=""><br class=""></div><div class="">-Chris</div></div></div></blockquote></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">I apologize for adding to this topic rather than starting a new one, but I figure people interested in subscripts would be more likely to see my question:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Is there a good reason subscripts cannot throw? Right now you can create a [safe: index] subscript to return an optional but you can't create one that returns an unwrapped value or throws.</div></div></blockquote><br class=""></div></span><div class="">Throwing accessors are mostly straightforward, but there is a big conceptual question: what happens if an accessor is called during error propagation? For example:</div><div class=""><br class=""></div><div class=""> objectWithThrowingSubscriptSet<wbr class="">ter[index].mutatingMethodThatC<wbr class="">anThrow()</div><div class=""><br class=""></div><div class=""><span id="m_-7479585401879917020m_-6348449611380270962x-apple-selection:end" class=""></span>If the method throws, we currently still call the setter in order to finish the access. If the setter can throw, then, we might end up with multiple errors being thrown at the same time, which isn't good — the language is put in the awkward position of having to invent an arbitrary resolution mechanism.</div><div class=""><br class=""></div><div class="">You might ask: why do we call the setter if an error is thrown? Well, it's complicated. One reason is that the implementation technique we use for generic access to subscripts and properties — accesses where we don't know how the subscript/property is implemented — doesn't know how to distinguish between *finishing* an access normally and *aborting* an access abnormally. Some kinds of property/subscript implementation — ones currently reserved for the standard library, but likely to be eventually offered to users in some form — depend on doing extra work no matter how the access is terminated, e.g. to release a buffer pointer. (In fact, in general this applies even to get/set implementations, because even if we decided not to call the setter when an error was thrown, we would at least need to destroy the index argument that we were going to pass to the setter.) In order to get consistent behavior between generic and non-generic accesses, we've just generally been finishing the access all the time.</div><div class=""><br class=""></div><div class="">I think it would be possible to teach this generic mechanism the difference between finishing and aborting an access, and thus to avoid calling setters or otherwise doing arbitrary work that's allowed to throw during an abort. However, we would first have to decide that those are indeed the correct semantics and that setters should not be called after a throw, and that would be a change in behavior.</div><div class=""><br class=""></div><div class="">John.</div></div><br class="">______________________________<wbr 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/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="m_-7479585401879917020gmail_signature" data-smartmail="gmail_signature">Chris Eidhof</div>
</div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span><br class=""></div></blockquote></div></div></div></div></div><br class="">______________________________<wbr class="">_________________<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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature">Chris Eidhof</div>
</div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></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>