Hello Chris, thanks for this draft!
May I suggest that the introduction mentions genericity on return type as well?
subscript<T>(_ index: Int) -> T
(I have database rows in mind.)
Gwendal
> Le 12 janv. 2017 à 18:53, Chris Eidhof via swift-evolution
> <[email protected]> a écrit :
>
> Ok, I've got a draft up as a gist:
> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25
> <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
> <[email protected] <mailto:[email protected]>> wrote:
>
>
> Sent from my iPhone
>
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution
> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution
>>> <[email protected] <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>>
>> --
>> Chris Eidhof
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
>
>
> --
> Chris Eidhof
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
