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

[Jose Cheyo Jimenez]

> On Jul 20, 2016, at 10:36 AM, Leonardo Pessoa <me at lmpessoa.com> wrote:
> 
> 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.

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

> L
> 
> 
> On 20 July 2016 at 14:17, Jose Cheyo Jimenez via swift-evolution
> <swift-evolution at swift.org> wrote:
>> 
>> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution
>> <swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>