The subscript is a crossover between a function and a computed
property, and depending how you look at it, you will find either ":"
to be a better fit if you argue that they are closer to properties, or
that "->" is better, if you argue that subscripts are closer to
Just want to understand this opinion. How subscript could be closer to function(method) than to property?
Calling subscript you don't use `()`
Subscript could be assigned to some value, just like property, method couldn't be.
What does `->` syntax mean for subscript setter? In all other parts of language `->` means 'returns', i.e. requirement to return some value. Here we have to read this as 'returns T but for setter it want to get T'
Setter of subscript *does not* return anything.
For me, subscript is *much* more like property with getter/setter, than method from any point of view(declaration or using).
···
On 20.07.2016 9:12, Dmitri Gribenko via swift-evolution wrote:
On Tue, Jul 19, 2016 at 10:50 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:
functions. I don't find either argument to be more convincing that
the other, so I don't see a reason to change this part of the
language.
I wouldn't mind if the change would be made though, but I think by
changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.
I think the colon has too little visual weight for this role. In a property declaration, the colon sits to the right of an identifier:
var widgetID: WidgetUUID
But in a subscript, it sits to the right of a long, punctuation-filled, and potentially convoluted parameter list:
subscript(id widgetID: WidgetUUID): Widget { … }
In this environment, the colon vanishes.
You trumpet it like it is a universal truth... I have been back into lots of ts for 2 weeks now and low and behold none of the colons have vanished yet ;-)
More seriously, I think u underestimate the way the brain just adapts. None of this is hard to read:
interface Hashable { getHash(): number }
Interface Dictionary { [name:string]:string|number }
interface T extends Hashable { }
class SomeTypeName<Type extends Hashable> {
public getHash():number {
return ...;
}
public type():this {
return Type;
}
}
function compare<T1 extends T, T2 extends T>(lhs:SomeTypeName<T1>, rhs:SomeTypeName<T2>):boolean {
return lhs.getHash() != rhs.getHash();
}
and neither is this:
export function newDataStore<T extends DataStore<U>, U> (ctor: { new (config:DataStoreConfig):T}, config:DataStoreConfig):T {
return new ctor(config)
}
···
On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Using arrow instead gives us a symbol that not only stands out more, but which is conventionally given spacing on both sides. Both of these assist you in seeing the symbol, helping you visually parse the declaration. It also helps that this symbol is not the same one used at least once and sometimes more often within the parameter list itself.
I understand where the impulse comes from, I really do. Looked at as an abstract question, colon is more correct, because there's no function involved here. But subscript syntax faces many of the same challenges that led to the adoption of the arrow in functions, and I think we have to go where those human factors lead us.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes, I think proposals on this topic are appropriate.
* Does this proposal fit well with the feel and direction of Swift?
No; I think that's where this proposal falls down. Swift happily emphasizes clarity over purity, and I think arrow is clearer.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Off the top of my head, I can't think of one with an analogous issue.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
If, as seems likely for lens support, we eventually supported inout functions:
func foo(x: Int) -> inout String {
get { return myStr }
set { myStr = newValue }
}
Would you feel differently about having `:` on subscript returns? Or would you want to use `:` on inout functions, too?
···
On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution <swift-evolution@swift.org> wrote:
However, the current notation of -> Type being used to declare an input parameter to set {} just strikes me as weird and wrong. The symbol -> means “returns a” or “yields”. Since we’re declaring a type that might be either inbound or outbound, the neutral : is more appropriate.
To me, subscripts have always seen more functions than properties for the fact that they can take arbitrary number of arguments. If we were to "clean up" its syntax, I'd rather align it with functions. Something along the lines of
* Is the problem being addressed significant enough to warrant a change to Swift?
No. More importantly, the change is a regression visually.
* Does this proposal fit well with the feel and direction of Swift?
It's an attempt of a syntax dress-up.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read of proposal and discussion on ML.
Daniel Duan
···
Sent from my iPhone
On Jul 20, 2016, at 10:17 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
+1 to clean up the syntax of subscripts. They acts as properties, not methods, so it is natural to express them with `:` and not with `->`.
Actually, I'd prefer additional change to use instead of () in declaration like:
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I got to second this suggestion. To me this is an elegant solution.
If subscripts are so special that Swift decided to give it its own name (as oppose to just making it two functions),
why not declare it in a special way like the above?
I think that in addition to replacing -> with : if we replaced () with then it would be much clearer that this is not a function or property.
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I don’t see another place in the language where would make more sense than here:
Otherwise I don’t see replacing -> with : as a big win like Dmitri Gribenko said down thread ->
I think by changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.
especially if thinking about "Future directions" and confusion with parameterised accessor syntax(both declared with `()` but first used with `` and second with `()`).
On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I'd personally leave it as is, but am kind of indifferent on the matter.
The subscript is a hybrid between var and func and with the arguments, it always felt more of a function to me, without them, it felt more like a var to me.
The logical thing might be to have double-syntax:
subscript: Int {
get { … }
set { … }
}
I've never seen a subscript without parameters before and have a hard time imagining what it would be used for. Wouldn't that be better served with just a property?
···
On 20 Jul 2016, at 07:58, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
but with parameters, leave the function model:
subscript(parameter: Int) -> ElementType {
get { … }
set { … }
}
But that brings a certain inconsistency to the language...
On Jul 20, 2016, at 7:50 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
This seems irrelevant since Swift already has computed properties which pretend not to be a function.
···
On Jul 20, 2016, at 7:13 PM, Duan via swift-evolution <swift-evolution@swift.org> wrote:
* What is your evaluation of the proposal <x-apple-data-detectors://3>?
-1.
To me, subscripts have always seen more functions than properties for the fact that they can take arbitrary number of arguments. If we were to "clean up" its syntax, I'd rather align it with functions. Something along the lines of
* Is the problem being addressed significant enough to warrant a change to Swift?
No. More importantly, the change is a regression visually.
* Does this proposal fit well with the feel and direction of Swift?
It's an attempt of a syntax dress-up.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read of proposal and discussion on ML.
Daniel Duan
Sent from my iPhone
On Jul 20, 2016, at 10:17 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to clean up the syntax of subscripts. They acts as properties, not methods, so it is natural to express them with `:` and not with `->`.
Actually, I'd prefer additional change to use instead of () in declaration like:
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I got to second this suggestion. To me this is an elegant solution.
If subscripts are so special that Swift decided to give it its own name (as oppose to just making it two functions),
why not declare it in a special way like the above?
I think that in addition to replacing -> with : if we replaced () with then it would be much clearer that this is not a function or property.
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I don’t see another place in the language where would make more sense than here:
Otherwise I don’t see replacing -> with : as a big win like Dmitri Gribenko said down thread ->
I think by changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.
especially if thinking about "Future directions" and confusion with parameterised accessor syntax(both declared with `()` but first used with `` and second with `()`).
On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
However, the current notation of -> Type being used to declare an input parameter to set {} just strikes me as weird and wrong. The symbol -> means “returns a” or “yields”. Since we’re declaring a type that might be either inbound or outbound, the neutral : is more appropriate.
If, as seems likely for lens support, we eventually supported inout functions:
func foo(x: Int) -> inout String {
get { return myStr }
set { myStr = newValue }
}
Would you feel differently about having `:` on subscript returns? Or would you want to use `:` on inout functions, too?
I think this is semantically identical to the idea of named accessors listed as a future direction.
···
Sent from my iPad
On Jul 20, 2016, at 8:47 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution <swift-evolution@swift.org> wrote:
To the extent that one conceptualizes lenses as having a “natural" inherent directionality, it seems desirable for the declaration to express that. So at first glance, -> doesn’t seem out of place here.
On Jul 20, 2016, at 7:23 PM, Jaden Geller <jaden.geller@gmail.com> wrote:
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
This seems irrelevant since Swift already has computed properties which pretend not to be a function.
On Jul 20, 2016, at 7:13 PM, Duan via swift-evolution <swift-evolution@swift.org> wrote:
* What is your evaluation of the proposal?
-1.
To me, subscripts have always seen more functions than properties for the fact that they can take arbitrary number of arguments. If we were to "clean up" its syntax, I'd rather align it with functions. Something along the lines of
* Is the problem being addressed significant enough to warrant a change to Swift?
No. More importantly, the change is a regression visually.
* Does this proposal fit well with the feel and direction of Swift?
It's an attempt of a syntax dress-up.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read of proposal and discussion on ML.
Daniel Duan
Sent from my iPhone
On Jul 20, 2016, at 10:17 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
+1 to clean up the syntax of subscripts. They acts as properties, not methods, so it is natural to express them with `:` and not with `->`.
Actually, I'd prefer additional change to use instead of () in declaration like:
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I got to second this suggestion. To me this is an elegant solution.
If subscripts are so special that Swift decided to give it its own name (as oppose to just making it two functions),
why not declare it in a special way like the above?
I think that in addition to replacing -> with : if we replaced () with then it would be much clearer that this is not a function or property.
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I don’t see another place in the language where would make more sense than here:
Otherwise I don’t see replacing -> with : as a big win like Dmitri Gribenko said down thread ->
I think by changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.
especially if thinking about "Future directions" and confusion with parameterised accessor syntax(both declared with `()` but first used with `` and second with `()`).
On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I don't disagree with discussing other languages. I'm just pointing out that C++ doesn't have a notion of computed properties, so subscript couldn't pretend to be a computed property even if it'd like! Python does have a similar construct, but it's computed properties *also* look like functions (you first define a set_foo() and a get_foo() before making the property) so it is also not relevant.
···
On Jul 20, 2016, at 7:24 PM, Duan <daniel@duan.org> wrote:
It's part of the review template :)
Daniel Duan
Sent from my iPhone
On Jul 20, 2016, at 7:23 PM, Jaden Geller <jaden.geller@gmail.com <mailto:jaden.geller@gmail.com>> wrote:
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
This seems irrelevant since Swift already has computed properties which pretend not to be a function.
On Jul 20, 2016, at 7:13 PM, Duan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
* What is your evaluation of the proposal <x-apple-data-detectors://3>?
-1.
To me, subscripts have always seen more functions than properties for the fact that they can take arbitrary number of arguments. If we were to "clean up" its syntax, I'd rather align it with functions. Something along the lines of
* Is the problem being addressed significant enough to warrant a change to Swift?
No. More importantly, the change is a regression visually.
* Does this proposal fit well with the feel and direction of Swift?
It's an attempt of a syntax dress-up.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read of proposal and discussion on ML.
Daniel Duan
Sent from my iPhone
On Jul 20, 2016, at 10:17 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to clean up the syntax of subscripts. They acts as properties, not methods, so it is natural to express them with `:` and not with `->`.
Actually, I'd prefer additional change to use instead of () in declaration like:
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I got to second this suggestion. To me this is an elegant solution.
If subscripts are so special that Swift decided to give it its own name (as oppose to just making it two functions),
why not declare it in a special way like the above?
I think that in addition to replacing -> with : if we replaced () with then it would be much clearer that this is not a function or property.
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I don’t see another place in the language where would make more sense than here:
Otherwise I don’t see replacing -> with : as a big win like Dmitri Gribenko said down thread ->
I think by changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.
especially if thinking about "Future directions" and confusion with parameterised accessor syntax(both declared with `()` but first used with `` and second with `()`).
On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I think there’s some value to point out these counterparts even when we are trying to do something new. Specifically, how much would we have lost, if we didn’t accept the proposal? By looking at these examples, one might conclude “not much”.
Also, it’s not the main reason I’m against this change.
···
On Jul 20, 2016, at 8:06 PM, Jaden Geller <jaden.geller@gmail.com> wrote:
I don't disagree with discussing other languages. I'm just pointing out that C++ doesn't have a notion of computed properties, so subscript couldn't pretend to be a computed property even if it'd like! Python does have a similar construct, but it's computed properties *also* look like functions (you first define a set_foo() and a get_foo() before making the property) so it is also not relevant.
On Jul 20, 2016, at 7:24 PM, Duan <daniel@duan.org <mailto:daniel@duan.org>> wrote:
It's part of the review template :)
Daniel Duan
Sent from my iPhone
On Jul 20, 2016, at 7:23 PM, Jaden Geller <jaden.geller@gmail.com <mailto:jaden.geller@gmail.com>> wrote:
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
This seems irrelevant since Swift already has computed properties which pretend not to be a function.
On Jul 20, 2016, at 7:13 PM, Duan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
* What is your evaluation of the proposal <x-apple-data-detectors://3>?
-1.
To me, subscripts have always seen more functions than properties for the fact that they can take arbitrary number of arguments. If we were to "clean up" its syntax, I'd rather align it with functions. Something along the lines of
* Is the problem being addressed significant enough to warrant a change to Swift?
No. More importantly, the change is a regression visually.
* Does this proposal fit well with the feel and direction of Swift?
It's an attempt of a syntax dress-up.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Python's __getitem__() method, C++'s operator are some analogous examples. Non -of them pretend not to be a function. The users of these features appear to be satisfied by the decision.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read of proposal and discussion on ML.
Daniel Duan
Sent from my iPhone
On Jul 20, 2016, at 10:17 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to clean up the syntax of subscripts. They acts as properties, not methods, so it is natural to express them with `:` and not with `->`.
Actually, I'd prefer additional change to use instead of () in declaration like:
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I got to second this suggestion. To me this is an elegant solution.
If subscripts are so special that Swift decided to give it its own name (as oppose to just making it two functions),
why not declare it in a special way like the above?
I think that in addition to replacing -> with : if we replaced () with then it would be much clearer that this is not a function or property.
subscript[externalName internalName: ParamType] : ElementType {
get { … }
set { … }
}
I don’t see another place in the language where would make more sense than here:
Otherwise I don’t see replacing -> with : as a big win like Dmitri Gribenko said down thread ->
I think by changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.
especially if thinking about "Future directions" and confusion with parameterised accessor syntax(both declared with `()` but first used with `` and second with `()`).
On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
Hello Swift community,
The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at