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

[James Froggatt via swift-evolution]

Marking the return value is certainly a direction we could go, but my reasoning 
in this proposal was that ‘-> inout’ is semantically equivalent to the colon, 
as it exists today for computed properties.
I think this the result of this proposal will set the precedent for if/when we 
do add this feature, and personally I'd prefer the cleaner syntax of the colon.

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID:  

>On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution 
> wrote:
> 
> However, the current notation of -> Type being used to declare an input 
> parameter to set {} just strikes me as weird and wrong. The symbol -> means 
> “returns a” or “yields”. Since we’re declaring a type that might be either 
> inbound or outbound, the neutral : is more appropriate.

If, as seems likely for lens support, we eventually supported inout functions:

func foo(x: Int) -> inout String {
get { return myStr }
set { myStr = newValue }
}

Would you feel differently about having `:` on subscript returns? Or would you 
want to use `:` on inout functions, too?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

:

- End Message - 



From James F
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Froggatt via swift-evolution]

Yeah, you might be right about the style, though to be honest I'm not entirely 
sure what the rule is for this. My reasoning was that if a space before a colon 
is justified anywhere, it should be acceptable here.

I'm not sure whether it's possible to update the proposal once submitted. 
Realised shortly after submitting how to add syntax highlighting with 
swift, too.

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: <26ed5325-4952-44c5-a9de-8b2c727d9...@gmail.com> 

I’m +0.5 on this. I think it’s very natural to think of subscript as a 
parameterized property. I've felt like I’m doing mental gymnastics to 
reconcile the signature of the setter, and I think replacing `->` with `:` 
might actually make this easier to reason about.

I’m not sure why the style in the proposal differs from that that’s typical 
in Swift. Usually, there’s no space between the property name and the colon, 
a la: `subscript(index: Int): Element { … }`. I think the proposal should be 
updated to reflect typical Swift style unless it’s proposing a deviation here 
(which seems unlikely given the goal to unify the syntax with property syntax).

> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
>  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 { … }
> }
> 
> 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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

°(

- End Message - 



From James F
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Garth Snyder via swift-evolution]

> Brent Royal-Gordon: If, as seems likely for lens support, we eventually 
> supported inout functions:
> 
>   func foo(x: Int) -> inout String {
>   get { return myStr }
>   set { myStr = newValue }
>   }
> 
> Would you feel differently about having `:` on subscript returns? Or would 
> you want to use `:` on inout functions, too?

Since I haven’t used lenses 
 and had to look 
them up, I’m really not entitled to an opinion on this. But it’s an interesting 
question.

To the extent that one conceptualizes lenses as having a “natural" inherent 
directionality, it seems desirable for the declaration to express that. So at 
first glance, -> doesn’t seem out of place here.

Garth

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Duan via swift-evolution]

I think there’s some value to point out these counterparts even when we are 
trying to do something new. Specifically, how much would we have lost, if we 
didn’t accept the proposal? By looking at these examples, one might conclude 
“not much”.

Also, it’s not the main reason I’m against this change.

> On Jul 20, 2016, at 8:06 PM, Jaden Geller  wrote:
> 
> 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 > 
>> wrote:
>> 
>> It's part of the review template :)
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Jul 20, 2016, at 7:23 PM, Jaden Geller > > 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 
 > 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 
 > wrote:
 
> 
>> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
>> > 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 

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

[Jaden Geller via swift-evolution]

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  wrote:
> 
> It's part of the review template :)
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Jul 20, 2016, at 7:23 PM, Jaden Geller  > 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 
>>> > 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 
>>> > wrote:
>>> 
 
> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
> > 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 
>> 

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

[Duan via swift-evolution]

It's part of the review template :)

Daniel Duan
Sent from my iPhone

> On Jul 20, 2016, at 7:23 PM, Jaden Geller  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 
>>  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 
>>>  wrote:
>>> 
>>> 
 On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
  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 

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

[Duan via swift-evolution]

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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

On Jul 20, 2016, at 8:47 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution 
>>  wrote:
>> 
>> However, the current notation of -> Type being used to declare an input 
>> parameter to set {} just strikes me as weird and wrong. The symbol -> means 
>> “returns a” or “yields”. Since we’re declaring a type that might be either 
>> inbound or outbound, the neutral : is more appropriate.
> 
> If, as seems likely for lens support, we eventually supported inout functions:
> 
>func foo(x: Int) -> inout String {
>get { return myStr }
>set { myStr = newValue }
>}
> 
> Would you feel differently about having `:` on subscript returns? Or would 
> you want to use `:` on inout functions, too?

I think this is semantically identical to the idea of named accessors listed as 
a future direction.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution 
>  wrote:
> 
> However, the current notation of -> Type being used to declare an input 
> parameter to set {} just strikes me as weird and wrong. The symbol -> means 
> “returns a” or “yields”. Since we’re declaring a type that might be either 
> inbound or outbound, the neutral : is more appropriate.

If, as seems likely for lens support, we eventually supported inout functions:

func foo(x: Int) -> inout String {
get { return myStr }
set { myStr = newValue }
}

Would you feel differently about having `:` on subscript returns? Or would you 
want to use `:` on inout functions, too?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

> * What is your evaluation of the proposal?

I would be in favor if we make the change to square brackets that everyone is 
talking about.  Otherwise I am indifferent.


> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

I do feel that the current setter behavior is confusing.


> * Does this proposal fit well with the feel and direction of Swift?

As people have said, it doesn’t really fit with either function or property 
syntax, so we should consider the square bracket syntax.

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
N/A


> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick read of the proposal and discussion

Thanks,
Jon


> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Garth Snyder via swift-evolution]

+1

I prefer the current syntax from a subjective and readability perspective.

However, the current notation of -> Type being used to declare an input 
parameter to set {} just strikes me as weird and wrong. The symbol -> means 
“returns a” or “yields”. Since we’re declaring a type that might be either 
inbound or outbound, the neutral : is more appropriate.

I didn’t initially think this was all that important to address, but having 
considered it more, I agree that it’s a wart worth excising and is worth the 
disruption for users.

Garth

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 20, 2016, at 10:36 AM, Leonardo Pessoa  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
>  wrote:
>> 
>> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution
>>  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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

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

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

[Nevin Brackett-Rozinsky via swift-evolution]

I’ll concur with Jose:

Either replace parens with square brackets so the declaration of a
subscript matches its point of use (in which case a colon would be
acceptable) or else leave it as it is.

I am (-1) on the proposal as written, (+1) on square brackets for
subscripts (with either colon or arrow), and (+0.5) on keeping the status
quo.

Nevin



On Wed, Jul 20, 2016 at 1:17 PM, Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution <
> swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
>  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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jaden Geller via swift-evolution]

I’m +0.5 on this. I think it’s very natural to think of subscript as a 
parameterized property. I've felt like I’m doing mental gymnastics to reconcile 
the signature of the setter, and I think replacing `->` with `:` might actually 
make this easier to reason about.

I’m not sure why the style in the proposal differs from that that’s typical in 
Swift. Usually, there’s no space between the property name and the colon, a la: 
`subscript(index: Int): Element { … }`. I think the proposal should be updated 
to reflect typical Swift style unless it’s proposing a deviation here (which 
seems unlikely given the goal to unify the syntax with property syntax).

> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution 
>  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 { … }
> }
> 
> 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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

-1 from me. Getter subscipts are closer to functions, where name is
`subscript`.
Of course, they are called with brackets, but they are still a kind of
functions, and when we assign them to function variables, they get type
that matches their declaration.

2016-07-20 8:50 GMT+03:00 Chris Lattner via swift-evolution <
swift-evolution@swift.org>:

> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Anton, I think where people find the current notation problematic is with
_setters_, not getters.

On Wed, Jul 20, 2016 at 11:58 AM, Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 from me. Getter subscipts are closer to functions, where name is
> `subscript`.
> Of course, they are called with brackets, but they are still a kind of
> functions, and when we assign them to function variables, they get type
> that matches their declaration.
>
> 2016-07-20 8:50 GMT+03:00 Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
>
>> 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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>* What is your evaluation of the proposal?
> 
> I think the colon has too little visual weight for this role. In a property 
> declaration, the colon sits to the right of an identifier:
> 
>var widgetID: WidgetUUID
> 
> But in a subscript, it sits to the right of a long, punctuation-filled, and 
> potentially convoluted parameter list:
> 
>subscript(id widgetID: WidgetUUID): Widget { … }
> 
> In this environment, the colon vanishes.

You trumpet it like it is a universal truth... I have been back into lots of ts 
for 2 weeks now and low and behold none of the colons have vanished yet ;-) 
More seriously, I think u underestimate the way the brain just adapts. None of 
this is hard to read:

interface Hashable { getHash(): number }
Interface Dictionary { [name:string]:string|number }
interface T extends Hashable { }
class SomeTypeName {
  public getHash():number {
return ...;
  }
  public type():this {
return Type;
  }
}
function compare(lhs:SomeTypeName, 
rhs:SomeTypeName):boolean {
  return lhs.getHash() != rhs.getHash();
}

and neither is this:

export function newDataStore, U> (ctor: { new 
(config:DataStoreConfig):T}, config:DataStoreConfig):T {
   return new ctor(config)
}


> Using arrow instead gives us a symbol that not only stands out more, but 
> which is conventionally given spacing on both sides. Both of these assist you 
> in seeing the symbol, helping you visually parse the declaration. It also 
> helps that this symbol is not the same one used at least once and sometimes 
> more often within the parameter list itself.
> 
> Thus, we have the current syntax:
> 
>subscript(id widgetID: WidgetUUID) -> Widget { … }
> 
> I understand where the impulse comes from, I really do. Looked at as an 
> abstract question, colon is more correct, because there's no function 
> involved here. But subscript syntax faces many of the same challenges that 
> led to the adoption of the arrow in functions, and I think we have to go 
> where those human factors lead us.
> 
>>* Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes, I think proposals on this topic are appropriate.
> 
>>* Does this proposal fit well with the feel and direction of Swift?
> 
> No; I think that's where this proposal falls down. Swift happily emphasizes 
> clarity over purity, and I think arrow is clearer.
> 
>>* If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> Off the top of my head, I can't think of one with an analogous issue.
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Glance.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

On 20 July 2016 at 02: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
>
> * What is your evaluation of the proposal?

I feel a little reluctant to approve this but I'll have to give my +1
just for the sake of consistency. Computed properties already use
colons despite being internally just functions just like subscripts
and the syntax is almost the same. I agree there may be an issue with
readability but so do with computed properties and I didn't see anyone
complaining about that syntax.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

Despite accepting the change, I still don't think it is significant
enough. It is merely a cosmetic change that adds/enhances nothing to
the language.

> * Does this proposal fit well with the feel and direction of Swift?

I'm not sure but it grants a bit more of consistency in its syntax.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Other languages I worked with make no distinction on how you declare
the type of variables, function returns and properties. I'm not saying
"drop the arrows" thou.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal and followed the thread discussing it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

On 20.07.2016 9:12, Dmitri Gribenko via swift-evolution wrote:

On Tue, Jul 19, 2016 at 10:50 PM, 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


Weakly against.

The subscript is a crossover between a function and a computed
property, and depending how you look at it, you will find either ":"
to be a better fit if you argue that they are closer to properties, or
that "->" is better, if you argue that subscripts are closer to


Just want to understand this opinion. How subscript could be closer to 
function(method) than to property?

Calling subscript you don't use `()`
Subscript could be assigned to some value, just like property, method 
couldn't be.
What does `->` syntax mean for subscript setter? In all other parts of 
language `->` means 'returns', i.e. requirement to return some value. Here 
we have to read this as 'returns T but for setter it want to get T'

Setter of subscript *does not* return anything.

For me, subscript is *much* more like property with getter/setter, than 
method from any point of view(declaration or using).



functions.  I don't find either argument to be more convincing that
the other, so I don't see a reason to change this part of the
language.

I wouldn't mind if the change would be made though, but I think by
changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.

Dmitri


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

+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 { … }
}

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Jul 20, 2016, at 5:16 AM, Brent Royal-Gordon  
> wrote:
> 
>   subscript(id widgetID: WidgetUUID): Widget { … }

Plus, as a minor issue, certain chat clients which shall remain nameless will 
convert `):` to a graphical smiley. That will make some programmers frown.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

I think the colon has too little visual weight for this role. In a property 
declaration, the colon sits to the right of an identifier:

var widgetID: WidgetUUID

But in a subscript, it sits to the right of a long, punctuation-filled, and 
potentially convoluted parameter list:

subscript(id widgetID: WidgetUUID): Widget { … }

In this environment, the colon vanishes. Using arrow instead gives us a symbol 
that not only stands out more, but which is conventionally given spacing on 
both sides. Both of these assist you in seeing the symbol, helping you visually 
parse the declaration. It also helps that this symbol is not the same one used 
at least once and sometimes more often within the parameter list itself.

Thus, we have the current syntax:

subscript(id widgetID: WidgetUUID) -> Widget { … }

I understand where the impulse comes from, I really do. Looked at as an 
abstract question, colon is more correct, because there's no function involved 
here. But subscript syntax faces many of the same challenges that led to the 
adoption of the arrow in functions, and I think we have to go where those human 
factors lead us.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes, I think proposals on this topic are appropriate.

>   * Does this proposal fit well with the feel and direction of Swift?

No; I think that's where this proposal falls down. Swift happily emphasizes 
clarity over purity, and I think arrow is clearer.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Off the top of my head, I can't think of one with an analogous issue.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Glance.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

I'm leaning towards in favour, but very marginally as to be frank I'm not that 
bothered either way. The subscript is a definite hybrid of property and 
function, but then so is a computed property, only the subscript has the 
possibility of arguments, which makes it slightly more function oriented.

So I don't know, I'd say the fact that a subscript with setter makes it more 
like a property overall, but again it's a very slim difference.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Not really; I don't think anyone is losing any sleep over having to use 
function style declaration. It might be a little easier for newbies to use the 
colon, but I'm not sure as the duality doesn't make either style a clear 
winner; really we'd need more information about which people find easier to use.

>   * Does this proposal fit well with the feel and direction of Swift?

Both styles are Swifty, this may be very marginally better, but it's a tough 
call.
> 
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read, it's pretty straightforward though.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Davor Jankolija via swift-evolution]

> What is your evaluation of the proposal?

I’m afraid I’m against this proposal, since IMO colons are no better in this 
case than the arrow syntax.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

I understand that the current syntax isn’t as clear as it possible cold be, but 
as has been mentioned subscripts are kind of special when it comes to their 
syntax, so again IMO if anything they should have a totaly different syntax, 
the :-> syntax sort of makes sense but then again it does look awkward and 
there’s no predent in the language for it.

> Does this proposal fit well with the feel and direction of Swift?

Possibly, but if choosing between the proposed colon syntax and current one, I 
think Swift should stick to the current one.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I looked really hard at the current syntax and the proposed one :). 

Again, I understand why the proposal, just not sure on the colons as a better 
alternative to what we currently have.

- Davor

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

> On 20 Jul 2016, Chris Lattner wrote:
> 
> 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
> 
>   * What is your evaluation of the proposal?

I'm mildly in favour because I think (settable) subscripts are more similar to 
properties than functions. But is this change worth having in Swift 3? I'm a 
bit surprised it's discussed this late in the cycle.

Here are some considerations on the topic:

1. If we bring colons in, why not change the parentheses into brackets too? 
Like so:

public subscript[index: Int]: Element

2. If we change the arrows into colons but then later choose to make throwing 
subscripts possible, how could that be still done? Probable answer: by adding 
the `throws` specifier to the getter or setter as needed.

3. Do we want to address the fact that – unlike functions – subscript arguments 
currently have implicitly blank external names, i.e. that `subscript(at: Int)` 
and `subscript(_ at: Int)` are equivalent? I don't think we do; but if that's 
the case then it's probably a good idea to also make the declaration syntax 
less alike with functions. So that would be a small argument in favour of 
SE-0122.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Probably not at this stage. I think this change could be introduced even 
post-Swift 3, although that would then require maintaining both syntaxes for an 
extended period of time.

>   * Does this proposal fit well with the feel and direction of Swift?

I think so.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 20 Jul 2016, at 06: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?

I am quite against this change as it changes an understandable albeit some 
people may not think of it as perfect syntax with a syntax that is IMHO 
confusing actually. 

The -> symbol in much of Swift, especially in methods and method like bits like 
this one, is clearly understood as specifying what is being returned to the 
caller while the :  symbol is more prevalently associated with protocol 
conformance and subclassing for example.

>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

No, as I do not feel there is a problem actually.

>* Does this proposal fit well with the feel and direction of Swift?

No, the change is unnecessary in my opinion and not an improvement over what 
the language offers.

>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I do not think any language I have used would mix conformance/subtyping with 
the syntax for returning arguments.

>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> 

Followed the e-mail thread and read the proposal.

> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

> What is your evaluation of the proposal?

I'm not in favor of it because I see no tangible benefit, and it feels like we 
don't need changes that break source for the sake of breaking source already. I 
don't think that it's worth the effort.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

It's unclear to me that there was a problem in the first place. Saying that the 
arrow is "very much out of place" seems like a broad exaggeration to me. I'm 
also not in favor of accessors that throw either, if such a proposal ever comes 
to light.

> Does this proposal fit well with the feel and direction of Swift?

I'm lukewarm on that one.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

.NET implements indexers (subscripts) as properties. However, it's a common 
cause of confusion for people who want to access them using reflection. I agree 
that subscripts are not "obviously methods", but the .NET experience leads me 
to believe that they're not "obviously properties" either, so I'm fine with 
subscripts being their own thing.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Quick glance, read the whole proposal, didn't look at the discussion very much.

"Named accessors" as presented in the future directions could as well be 
implemented with the -> syntax for the return type. The biggest differentiating 
point is "var" instead of "func". This comment isn't meant to endorse or 
disapprove of named accessors, I'm just saying that we can have it 
independently of whether we change the syntax.

Félix

> Le 19 juil. 2016 à 22:50:37, Chris Lattner via swift-evolution 
>  a écrit :
> 
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dmitri Gribenko via swift-evolution]

On Tue, Jul 19, 2016 at 10:50 PM, 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

Weakly against.

The subscript is a crossover between a function and a computed
property, and depending how you look at it, you will find either ":"
to be a better fit if you argue that they are closer to properties, or
that "->" is better, if you argue that subscripts are closer to
functions.  I don't find either argument to be more convincing that
the other, so I don't see a reason to change this part of the
language.

I wouldn't mind if the change would be made though, but I think by
changing subscripts to use colons we would end in the opposite, but
totally symmetrical situation compared to what we have now.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

I'd personally leave it as is, but am kind of indifferent on the matter.

The subscript is a hybrid between var and func and with the arguments, it 
always felt more of a function to me, without them, it felt more like a var to 
me.

The logical thing might be to have double-syntax:

subscript: Int {
get { … }
set { … }
}

but with parameters, leave the function model:

subscript(parameter: Int) -> ElementType {
get { … }
set { … }
}

But that brings a certain inconsistency to the language...


> On Jul 20, 2016, at 7:50 AM, 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution