It's part of the review template :) Daniel Duan Sent from my iPhone
> On Jul 20, 2016, at 7:23 PM, Jaden Geller <[email protected]> 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 >> <[email protected]> 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 >> >> 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]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
