[swift-evolution] Generic Subscripts

Thu Jan 12 11:53:08 CST 2017

Ok, I've got a draft up as a gist:
https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25

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).

Thanks!

On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPhone
>
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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"?
>
>
> 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.
>
>  - Doug
>
>
>
> 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/b
>> rowse/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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/026da952/attachment.html>