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"?
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.
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution < >> email@example.com> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution < >> firstname.lastname@example.org> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution < >> email@example.com> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution < >> firstname.lastname@example.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/b
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.
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
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:
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
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
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.
swift-evolution mailing list