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 <[email protected]> wrote: > > 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] > <mailto:[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] <mailto:[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] <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
