[swift-evolution] Generic Subscripts

[Chris Eidhof]

Okay,

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"?

On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> [Forgot to CC swift-evolution the first time]
>
> 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: https://bugs.swift.org/
> browse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>
>
> 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.
>
> I’ve only heard positive reactions toward this feature, and it’s something
> that the standard library could make good use of.
>
>
> +1, this would be clearly great to happen.
>
> -Chris
>
>
>
> 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:
>
> 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.
>
>
> Throwing accessors are mostly straightforward, but there is a big
> conceptual question: what happens if an accessor is called during error
> propagation?  For example:
>
>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>
> 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.
>
> 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.
>
> 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.
>
> John.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Chris Eidhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170112/29fbe687/attachment.html>