[Review] SE-0122: Use colons for subscript declarations


(Chris Lattner) #1

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Dmitri Gribenko) #2

Weakly against.

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

Dmitri

···

On Tue, Jul 19, 2016 at 10:50 PM, 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:

        https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Félix Cloutier) #3

What is your evaluation of the proposal?

I'm not in favor of it because I see no tangible benefit, and it feels like we don't need changes that break source for the sake of breaking source already. I don't think that it's worth the effort.

Is the problem being addressed significant enough to warrant a change to Swift?

It's unclear to me that there was a problem in the first place. Saying that the arrow is "very much out of place" seems like a broad exaggeration to me. I'm also not in favor of accessors that throw either, if such a proposal ever comes to light.

Does this proposal fit well with the feel and direction of Swift?

I'm lukewarm on that one.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

.NET implements indexers (subscripts) as properties. However, it's a common cause of confusion for people who want to access them using reflection. I agree that subscripts are not "obviously methods", but the .NET experience leads me to believe that they're not "obviously properties" either, so I'm fine with subscripts being their own thing.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick glance, read the whole proposal, didn't look at the discussion very much.

"Named accessors" as presented in the future directions could as well be implemented with the -> syntax for the return type. The biggest differentiating point is "var" instead of "func". This comment isn't meant to endorse or disapprove of named accessors, I'm just saying that we can have it independently of whether we change the syntax.

Félix

···

Le 19 juil. 2016 à 22:50:37, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #4

  * What is your evaluation of the proposal?

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

Thus, we have the current syntax:

  subscript(id widgetID: WidgetUUID) -> Widget { … }

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?

Glance.

···

On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies


(Goffredo Marocchi) #5

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:

   https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

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?

I am quite against this change as it changes an understandable albeit some people may not think of it as perfect syntax with a syntax that is IMHO confusing actually.

The -> symbol in much of Swift, especially in methods and method like bits like this one, is clearly understood as specifying what is being returned to the caller while the : symbol is more prevalently associated with protocol conformance and subclassing for example.

   * Is the problem being addressed significant enough to warrant a change to Swift?

No, as I do not feel there is a problem actually.

   * Does this proposal fit well with the feel and direction of Swift?

No, the change is unnecessary in my opinion and not an improvement over what the language offers.

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I do not think any language I have used would mix conformance/subtyping with the syntax for returning arguments.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the e-mail thread and read the proposal.

···

Sent from my iPhone

On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charlie Monroe) #6

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 { … }
}

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Pyry Jahkola) #7

The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

  * What is your evaluation of the proposal?

I'm mildly in favour because I think (settable) subscripts are more similar to properties than functions. But is this change worth having in Swift 3? I'm a bit surprised it's discussed this late in the cycle.

Here are some considerations on the topic:

1. If we bring colons in, why not change the parentheses into brackets too? Like so:

    public subscript[index: Int]: Element

2. If we change the arrows into colons but then later choose to make throwing subscripts possible, how could that be still done? Probable answer: by adding the `throws` specifier to the getter or setter as needed.

3. Do we want to address the fact that – unlike functions – subscript arguments currently have implicitly blank external names, i.e. that `subscript(at: Int)` and `subscript(_ at: Int)` are equivalent? I don't think we do; but if that's the case then it's probably a good idea to also make the declaration syntax less alike with functions. So that would be a small argument in favour of SE-0122.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Probably not at this stage. I think this change could be introduced even post-Swift 3, although that would then require maintaining both syntaxes for an extended period of time.

  * Does this proposal fit well with the feel and direction of Swift?

I think so.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

— Pyry

···

On 20 Jul 2016, Chris Lattner wrote:


(Leonardo Pessoa) #8

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:

        https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

        * What is your evaluation of the proposal?

I feel a little reluctant to approve this but I'll have to give my +1
just for the sake of consistency. Computed properties already use
colons despite being internally just functions just like subscripts
and the syntax is almost the same. I agree there may be an issue with
readability but so do with computed properties and I didn't see anyone
complaining about that syntax.

        * Is the problem being addressed significant enough to warrant a change to Swift?

Despite accepting the change, I still don't think it is significant
enough. It is merely a cosmetic change that adds/enhances nothing to
the language.

        * Does this proposal fit well with the feel and direction of Swift?

I'm not sure but it grants a bit more of consistency in its syntax.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Other languages I worked with make no distinction on how you declare
the type of variables, function returns and properties. I'm not saying
"drop the arrows" thou.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal and followed the thread discussing it.

···

On 20 July 2016 at 02:50, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Haravikk) #9

  * What is your evaluation of the proposal?

I'm leaning towards in favour, but very marginally as to be frank I'm not that bothered either way. The subscript is a definite hybrid of property and function, but then so is a computed property, only the subscript has the possibility of arguments, which makes it slightly more function oriented.

So I don't know, I'd say the fact that a subscript with setter makes it more like a property overall, but again it's a very slim difference.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Not really; I don't think anyone is losing any sleep over having to use function style declaration. It might be a little easier for newbies to use the colon, but I'm not sure as the duality doesn't make either style a clear winner; really we'd need more information about which people find easier to use.

  * Does this proposal fit well with the feel and direction of Swift?

Both styles are Swifty, this may be very marginally better, but it's a tough call.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read, it's pretty straightforward though.

···

On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Vladimir) #10

+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 { … }
}

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #11

-1 from me. Getter subscipts are closer to functions, where name is
`subscript`.
Of course, they are called with brackets, but they are still a kind of
functions, and when we assign them to function variables, they get type
that matches their declaration.

···

2016-07-20 8:50 GMT+03:00 Chris Lattner via swift-evolution < swift-evolution@swift.org>:

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

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

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(James Froggatt) #12

   * What is your evaluation of the proposal?

I think colons better represent a subscript's relationship to its type, so in favour.
This could also set the precedent for future ‘parameterised accessor’ syntax in Swift, in which case I prefer this cleaner syntax to something like ‘-> inout’.

While there are parallels to functions, as some people have noted, I think the parallel is strictly the parameter list, which will remain either way. The semantic relationship to the type, which should be conveyed by the symbol, is much closer to that of computed properties, which use a colon.

   * Is the problem being addressed significant enough to warrant a change to Swift?

It's a minor pain point currently, but in the long term sets a precedent for future parameterised accessors.

   * Does this proposal fit well with the feel and direction of Swift?

It think this defines it, so N/A?

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Not sure how other languages handle this. This is a decision specifically on Swift's syntax, so we should go with what makes sense for Swift.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've read it through the proposal a couple of times, and wrote it once.


(Brent Royal-Gordon) #13

Plus, as a minor issue, certain chat clients which shall remain nameless will convert `):` to a graphical smiley. That will make some programmers frown.

···

On Jul 20, 2016, at 5:16 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

  subscript(id widgetID: WidgetUUID): Widget { … }

--
Brent Royal-Gordon
Architechies


(Jaden Geller) #14

I’m +0.5 on this. I think it’s very natural to think of subscript as a parameterized property. I've felt like I’m doing mental gymnastics to reconcile the signature of the setter, and I think replacing `->` with `:` might actually make this easier to reason about.

I’m not sure why the style in the proposal differs from that that’s typical in Swift. Usually, there’s no space between the property name and the colon, a la: `subscript(index: Int): Element { … }`. I think the proposal should be updated to reflect typical Swift style unless it’s proposing a deviation here (which seems unlikely given the goal to unify the syntax with property syntax).

···

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 { … }
}

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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


(Chéyo Jiménez) #15

+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 ->

···

On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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


(Chéyo Jiménez) #16

I like this syntax better. But do you guys think we could remove this
"subscript" prefix?

I like the subscripts to be explicit.

Could we actually bring subscripts closer to
computed properties by doing something like "var self[externaName
internalName : ParamType] : ElemenType"? That could also support the
idea of creating named subscripts by replacing self with another name.

:slight_smile: I can already see how this could turn swift into Objc.
I don’t think I like that idea. ;( People already abuse subscripts as it is.

···

On Jul 20, 2016, at 10:36 AM, Leonardo Pessoa <me@lmpessoa.com> wrote:

L

On 20 July 2016 at 14:17, 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:

https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

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

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #17

Anton, I think where people find the current notation problematic is with
_setters_, not getters.

···

On Wed, Jul 20, 2016 at 11:58 AM, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

-1 from me. Getter subscipts are closer to functions, where name is
`subscript`.
Of course, they are called with brackets, but they are still a kind of
functions, and when we assign them to function variables, they get type
that matches their declaration.

2016-07-20 8:50 GMT+03:00 Chris Lattner via swift-evolution <
swift-evolution@swift.org>:

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

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

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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


(Garth Snyder) #18

+1

I prefer the current syntax from a subjective and readability perspective.

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.

I didn’t initially think this was all that important to address, but having considered it more, I agree that it’s a wart worth excising and is worth the disruption for users.

Garth


#19

I’ll concur with Jose:

Either replace parens with square brackets so the declaration of a
subscript matches its point of use (in which case a colon would be
acceptable) or else leave it as it is.

I am (-1) on the proposal as written, (+1) on square brackets for
subscripts (with either colon or arrow), and (+0.5) on keeping the status
quo.

Nevin

···

On Wed, Jul 20, 2016 at 1:17 PM, 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:

https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

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

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #20

I like this syntax better. But do you guys think we could remove this
"subscript" prefix? Could we actually bring subscripts closer to
computed properties by doing something like "var self[externaName
internalName : ParamType] : ElemenType"? That could also support the
idea of creating named subscripts by replacing self with another name.

L

···

On 20 July 2016 at 14:17, 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:

https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

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

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution