> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> 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
>>>>
>>>> <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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
