> 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 > <[email protected]> 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 > > subscribe(get) func foo(_ x: X) -> Y > subscribe(set) func foo(_ y: Y) > > * 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 > <[email protected] <mailto:[email protected]>> wrote: > >> >>> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution >>> <[email protected] <mailto:[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 >>>> >>>> <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 >>>> <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 >>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>> >>>> Thank you, >>>> >>>> -Chris Lattner >>>> Review Manager >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
