Hi,
Recently, I've bumped into the lack of generic subscripts a few times.
There are a bunch of useful things you could do with it. It's in the
generics manifesto as well:
I'm thinking of drafting up a proposal for this (also thanks to
https://twitter.com/dgregor79/status/818868882316214274\).
Are there any good arguments against adding this?
--
Chris Eidhof
[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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
On Jan 10, 2017, at 9:46 AM, Chris Eidhof via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
Recently, I've bumped into the lack of generic subscripts a few times. There are a bunch of useful things you could do with it. It's in the generics manifesto as well: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
I'm thinking of drafting up a proposal for this (also thanks to https://twitter.com/dgregor79/status/818868882316214274\).
Are there any good arguments against adding this?
--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
None.
on Tue Jan 10 2017, Chris Eidhof <swift-evolution@swift.org> wrote:
Hi,
Recently, I've bumped into the lack of generic subscripts a few times.
There are a bunch of useful things you could do with it. It's in the
generics manifesto as well:
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscriptsI'm thinking of drafting up a proposal for this (also thanks to
https://twitter.com/dgregor79/status/818868882316214274\).Are there any good arguments against adding this?
--
-Dave
[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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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.
- Doug
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 9:46 AM, Chris Eidhof via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi,
Recently, I've bumped into the lack of generic subscripts a few times. There are a bunch of useful things you could do with it. It's in the generics manifesto as well: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
I'm thinking of drafting up a proposal for this (also thanks to https://twitter.com/dgregor79/status/818868882316214274\).
Are there any good arguments against adding this?
--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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.
- Doug
I was under the impression that it was part of the "Complete Generics" goal, specifically here: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
The “generics manifesto” is a set of ideas that are *heavily* biased by my own goals for the generics system. They’re not plan-of-record, and some might even be terrible ideas for Swift. Each thing there still needs to go through the usual swift-evolution process to get proper design treatment before becoming a part of the language, and I expect that process to flush out better ideas/problems with those ideas/unexpected interactions/etc.
Will most of the other unimplemented points need proposals, as well?
Yes.
- Doug
On Jan 10, 2017, at 1:44 PM, Stephen Celis <stephen.celis@gmail.com> wrote:
On Jan 10, 2017, at 2:40 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
I was under the impression that it was part of the "Complete Generics" goal, specifically here: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
Will most of the other unimplemented points need proposals, as well?
Stephen
On Jan 10, 2017, at 2:40 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
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.
- Doug
+1, this would be clearly great to happen.
-Chris
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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.
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.
Thanks, -- E
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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
Throwing subscripts (and properties) do seem to fit well into the language model. There’s a well-written proposal draft by Brent here:
- Doug
On Jan 11, 2017, at 10:32 AM, Erica Sadun <erica@ericasadun.com> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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.
[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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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.
These topics do tend to come up together they are the two unnecessary limitations subscripts have right now. I hope both make it into Swift 4. I’m sure we’ll see a proposal after phase 2 opens up.
On Jan 11, 2017, at 12:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Thanks, -- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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.
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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.
Just a request that posters update the subject line when the topic of
discussion changes.
Thanks,
Dave
on Wed Jan 11 2017, Erica Sadun <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org > >> <mailto:swift-evolution@swift.org>> >> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution >>>> <swift-evolution@swift.org >>>> <mailto:swift-evolution@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:
[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub
<[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;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.Thanks, -- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Dave
[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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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.
These topics do tend to come up together they are the two unnecessary limitations subscripts have right now. I hope both make it into Swift 4. I’m sure we’ll see a proposal after phase 2 opens up.
Another limitation is that subscripts cannot have default arguments. I don’t believe this even requires an evolution proposal, it’s a quirk of the implementation and can be fixed by cleaning up some duplicated code paths in SILGen. If anyone is interested in looking at this I can point you to the code in question.
Slava
On Jan 11, 2017, at 10:53 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Thanks, -- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
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@swift.org> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution < > swift-evolution@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%22It’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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
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"?
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
Sent from my iPhone
On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Ok, I've got a draft up as a gist:
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@swift.org> wrote:
Sent from my iPhone
On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution < > swift-evolution@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@swift.org> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution < >> swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution < >> swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution < >> swift-evolution@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: Issues · apple/swift · GitHub
rowse/SR-115?jql=text%20~%20%22Generic%20subscript%22It’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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Chris Eidhof
Thanks for putting this together! I’m looking forward to seeing this make it into the language!
On Jan 12, 2017, at 11:53 AM, Chris Eidhof via swift-evolution <swift-evolution@swift.org> wrote:
Ok, I've got a draft up as a gist: generic-subscripts.md · GitHub
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@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Ok, I've got a draft up as a gist: generic-subscripts.md · GitHub
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).
It won’t change the ABI of existing subscript calls, but if the standard library introduces new generic subscripts that replace older non-generic subscripts, it will impact ABI.
Slava
On Jan 12, 2017, at 9:53 AM, Chris Eidhof via swift-evolution <swift-evolution@swift.org> wrote:
Thanks!
On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Ok, I've got a draft up as a gist: generic-subscripts.md · GitHub
Please remember to fill in the title (rather than “Feature name”). Otherwise… there’s not much to say. It’s a straightforward addition. Thanks for working on it!
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).
What Slava said!
- Doug
On Jan 12, 2017, at 9:53 AM, Chris Eidhof <chris@eidhof.nl> wrote:
Thanks!
On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
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 <swift-evolution@swift.org> a écrit :
Ok, I've got a draft up as a gist: generic-subscripts.md · GitHub
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@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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: [SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub <[SR-115] Support generic constraints in subscripts · Issue #42737 · apple/swift · GitHub;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution