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 <[email protected]> wrote: > > On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
