Proposal for Replacing Keyword "subscript" with "subs"

I encourage you to read the Swift API Design Guidelines
<https://swift.org/documentation/api-design-guidelines.html&gt;, as there are
a couple of things there that discourage what you are suggesting:

   - "*Clarity is more important than brevity*. Although Swift code can be
   compact, it is a *non-goal* to enable the smallest possible code with
   the fewest characters. Brevity in Swift code, where it occurs, is a
   side-effect of the strong type system and features that naturally reduce
   boilerplate."

···

-

   *Avoid abbreviations*. Abbreviations, especially non-standard ones, are
   effectively terms-of-art, because understanding depends on correctly
   translating them into their non-abbreviated forms.

   The intended meaning for any abbreviation you use should be easily found
   by a web search.

Thanks,
Seth

On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution < swift-evolution@swift.org> wrote:

Thank you for responding so late!

I agree with you that "subs" is not very obvious for subscript. While
learning swift, I have a feeling that it contains so many long words as the
keywords, such as

fallthrough, dynamicType, associativity, convenience, nonmutating,
precedence, etc..

I understand there is a need for clarity. But I think it's also important
to keep a concise and simple naming style where it's possible.

Thanks again.

------------------------------
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript"
with "subs"
From: jackl@apple.com
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org
To: feijian_sun@hotmail.com

It’s non-obvious to me that “subs” is short for subscript, whereas “init”
and “func” have only one obvious expansion.

Jack

On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution < > swift-evolution@swift.org> wrote:

Hello,

I have a proposal to replace the long keyword "subscript" with the shorter
version, "subs". The idea is to keep the concise naming style on the
language keywords, like "init" and "func".

So, Instead of:

subscript(index: Int) -> Int {
        ... ...
}

we could simply do:

subs(index: Int) -> Int{
        ... ...
}

Does this mean a big change on the parser side? what do you think?

Thank you!
_______________________________________________
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

Thanks for your suggestion!
But you're talking about the guidelines for Swift API Design while I'm proposing a keyword change in the language itself. I think they are not the same subjects.
The language itself uses many abbreviations as its keywords. If you search for 'var' on web, for example, you won't easily find it stands for 'variable'. Does it mean it violates the guidelines?

···

From: sethfri@gmail.com
Date: Thu, 10 Dec 2015 18:58:45 -0800
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: feijian_sun@hotmail.com; jackl@apple.com
CC: swift-evolution@swift.org

I encourage you to read the Swift API Design Guidelines, as there are a couple of things there that discourage what you are suggesting:"Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate."Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms.The intended meaning for any abbreviation you use should be easily found by a web search.Thanks,Seth
On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution <swift-evolution@swift.org> wrote:

Thank you for responding so late!
I agree with you that "subs" is not very obvious for subscript. While learning swift, I have a feeling that it contains so many long words as the keywords, such as
fallthrough, dynamicType, associativity, convenience, nonmutating, precedence, etc..
I understand there is a need for clarity. But I think it's also important to keep a concise and simple naming style where it's possible.
Thanks again.
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
From: jackl@apple.com
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org
To: feijian_sun@hotmail.com

It’s non-obvious to me that “subs” is short for subscript, whereas “init” and “func” have only one obvious expansion.
Jack
On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org> wrote:
Hello, I have a proposal to replace the long keyword "subscript" with the shorter version, "subs". The idea is to keep the concise naming style on the language keywords, like "init" and "func".So, Instead of:subscript(index: Int) -> Int { ... ...}we could simply do:subs(index: Int) -> Int{ ... ...}Does this mean a big change on the parser side? what do you think?Thank you! _______________________________________________swift-evolution mailing listswift-evolution@swift.orghttps://lists.swift.org/mailman/listinfo/swift-evolution
                 
_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms

I think the language tries to follow those guidelines as well. Also, “subs” is a very non-standard abbreviation. On the other hand, “init” and “var” are standard and very well known.

-David

I disagree that API for libraries and API for the language are different
subjects, otherwise that would make one feel rather unnatural when compared
to the other.

As for your specific example, a quick Google search for "var programming"
or "var computer science" will quickly tell you what the word means. A
search for "var" by itself does not, same with "func", but I don't think we
should be so pedantic that we insist on single word web searches.

Thanks,
Seth

···

On Thu, Dec 10, 2015 at 7:09 PM Feijian Sun <feijian_sun@hotmail.com> wrote:

Thanks for your suggestion!

But you're talking about the guidelines for Swift API Design while I'm
proposing a keyword change in the language itself. I think they are not the
same subjects.

The language itself uses many abbreviations as its keywords. If you search
for 'var' on web, for example, you won't easily find it stands for
'variable'. Does it mean it violates the guidelines?

------------------------------
From: sethfri@gmail.com
Date: Thu, 10 Dec 2015 18:58:45 -0800

Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript"
with "subs"
To: feijian_sun@hotmail.com; jackl@apple.com
CC: swift-evolution@swift.org

I encourage you to read the Swift API Design Guidelines
<https://swift.org/documentation/api-design-guidelines.html&gt;, as there
are a couple of things there that discourage what you are suggesting:

   - "*Clarity is more important than brevity*. Although Swift code can
   be compact, it is a *non-goal* to enable the smallest possible code
   with the fewest characters. Brevity in Swift code, where it occurs, is a
   side-effect of the strong type system and features that naturally reduce
   boilerplate."
   -

   *Avoid abbreviations*. Abbreviations, especially non-standard ones,
   are effectively terms-of-art, because understanding depends on correctly
   translating them into their non-abbreviated forms.

   The intended meaning for any abbreviation you use should be easily
   found by a web search.

Thanks,
Seth

On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution < > swift-evolution@swift.org> wrote:

Thank you for responding so late!

I agree with you that "subs" is not very obvious for subscript. While
learning swift, I have a feeling that it contains so many long words as the
keywords, such as

fallthrough, dynamicType, associativity, convenience, nonmutating,
precedence, etc..

I understand there is a need for clarity. But I think it's also important
to keep a concise and simple naming style where it's possible.

Thanks again.

------------------------------
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript"
with "subs"
From: jackl@apple.com
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org
To: feijian_sun@hotmail.com

It’s non-obvious to me that “subs” is short for subscript, whereas “init”
and “func” have only one obvious expansion.

Jack

On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution < > swift-evolution@swift.org> wrote:

Hello,

I have a proposal to replace the long keyword "subscript" with the shorter
version, "subs". The idea is to keep the concise naming style on the
language keywords, like "init" and "func".

So, Instead of:

subscript(index: Int) -> Int {
        ... ...
}

we could simply do:

subs(index: Int) -> Int{
        ... ...
}

Does this mean a big change on the parser side? what do you think?

Thank you!
_______________________________________________
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

Sorry, but I still think that a language itself and the API created with the language are two different things. A language can use any abbreviations as its keywords as long as they are defined clearly. But the names used for API are created by developers and should follow some common guidelines.
Just my own opinions. But good talk.
Thanks.

···

From: sethfri@gmail.com
Date: Thu, 10 Dec 2015 19:25:25 -0800
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: feijian_sun@hotmail.com
CC: jackl@apple.com; swift-evolution@swift.org

I disagree that API for libraries and API for the language are different subjects, otherwise that would make one feel rather unnatural when compared to the other.
As for your specific example, a quick Google search for "var programming" or "var computer science" will quickly tell you what the word means. A search for "var" by itself does not, same with "func", but I don't think we should be so pedantic that we insist on single word web searches.
Thanks,Seth

On Thu, Dec 10, 2015 at 7:09 PM Feijian Sun <feijian_sun@hotmail.com> wrote:

Thanks for your suggestion!
But you're talking about the guidelines for Swift API Design while I'm proposing a keyword change in the language itself. I think they are not the same subjects.
The language itself uses many abbreviations as its keywords. If you search for 'var' on web, for example, you won't easily find it stands for 'variable'. Does it mean it violates the guidelines?

From: sethfri@gmail.com
Date: Thu, 10 Dec 2015 18:58:45 -0800
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: feijian_sun@hotmail.com; jackl@apple.com
CC: swift-evolution@swift.org

I encourage you to read the Swift API Design Guidelines, as there are a couple of things there that discourage what you are suggesting:"Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate."Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms.The intended meaning for any abbreviation you use should be easily found by a web search.Thanks,Seth
On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution <swift-evolution@swift.org> wrote:

Thank you for responding so late!
I agree with you that "subs" is not very obvious for subscript. While learning swift, I have a feeling that it contains so many long words as the keywords, such as
fallthrough, dynamicType, associativity, convenience, nonmutating, precedence, etc..
I understand there is a need for clarity. But I think it's also important to keep a concise and simple naming style where it's possible.
Thanks again.
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
From: jackl@apple.com
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org
To: feijian_sun@hotmail.com

It’s non-obvious to me that “subs” is short for subscript, whereas “init” and “func” have only one obvious expansion.
Jack
On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org> wrote:
Hello, I have a proposal to replace the long keyword "subscript" with the shorter version, "subs". The idea is to keep the concise naming style on the language keywords, like "init" and "func".So, Instead of:subscript(index: Int) -> Int { ... ...}we could simply do:subs(index: Int) -> Int{ ... ...}Does this mean a big change on the parser side? what do you think?Thank you! _______________________________________________swift-evolution mailing listswift-evolution@swift.orghttps://lists.swift.org/mailman/listinfo/swift-evolution
                 
_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

The language itself uses many abbreviations as its keywords. If you search for 'var' on web, for example, you won't easily find it stands for 'variable'. Does it mean it violates the guidelines?

Actually, a Google search for just ‘var’ yields results pointing to JavaScript, C#, and HTML on the first page. A search for ‘init’ immediately describes the init process on Unix systems, as well as many other programming related results. Following any of these will let you understand the meaning of ‘init’ or ‘var’ pretty quickly. OTOH, ‘subs’ gives lots of results for sandwiches, but nothing programming related.

As a concert example of confusion that can arise, String implements subscript(), but ‘subs’ could just as easily stand for ‘substring’ in this context.

FKL

···

On Dec 10, 2015, at 10:09 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org> wrote:

Thanks for your suggestion!

But you're talking about the guidelines for Swift API Design while I'm proposing a keyword change in the language itself. I think they are not the same subjects.

From: sethfri@gmail.com <mailto:sethfri@gmail.com>
Date: Thu, 10 Dec 2015 18:58:45 -0800
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: feijian_sun@hotmail.com <mailto:feijian_sun@hotmail.com>; jackl@apple.com <mailto:jackl@apple.com>
CC: swift-evolution@swift.org <mailto:swift-evolution@swift.org>

I encourage you to read the Swift API Design Guidelines <https://swift.org/documentation/api-design-guidelines.html&gt;, as there are a couple of things there that discourage what you are suggesting:
"Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate."
Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms.
The intended meaning for any abbreviation you use should be easily found by a web search.
Thanks,
Seth

On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Thank you for responding so late!

I agree with you that "subs" is not very obvious for subscript. While learning swift, I have a feeling that it contains so many long words as the keywords, such as

fallthrough, dynamicType, associativity, convenience, nonmutating, precedence, etc..

I understand there is a need for clarity. But I think it's also important to keep a concise and simple naming style where it's possible.

Thanks again.

Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
From: jackl@apple.com <mailto:jackl@apple.com>
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org <mailto:swift-evolution@swift.org>
To: feijian_sun@hotmail.com <mailto:feijian_sun@hotmail.com>

It’s non-obvious to me that “subs” is short for subscript, whereas “init” and “func” have only one obvious expansion.

Jack
On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello,

I have a proposal to replace the long keyword "subscript" with the shorter version, "subs". The idea is to keep the concise naming style on the language keywords, like "init" and "func".

So, Instead of:

subscript(index: Int) -> Int {
        ... ...
}

we could simply do:

subs(index: Int) -> Int{
        ... ...
}

Does this mean a big change on the parser side? what do you think?

Thank you!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

The language itself uses many abbreviations as its keywords. If you search for 'var' on web, for example, you won't easily find it stands for 'variable'. Does it mean it violates the guidelines?

Actually, a Google search for just ‘var’ yields results pointing to JavaScript, C#, and HTML on the first page. A search for ‘init’ immediately describes the init process on Unix systems, as well as many other programming related results. Following any of these will let you understand the meaning of ‘init’ or ‘var’ pretty quickly. OTOH, ‘subs’ gives lots of results for sandwiches, but nothing programming related.

As a concert example of confusion that can arise, String implements subscript(), but ‘subs’ could just as easily stand for ‘substring’ in this context.

“var", “func", and “struct" are exceptions to the general rule because they’re so prominent; even novice Swift programmers will quickly learn these three concepts. “subscript” is probably at least three orders of magnitude less common, and many programmers will not be immediately familiar with it, so it’s far more important to be clear than succinct.

John.

···

On Dec 10, 2015, at 7:41 PM, Frederick Kellison-Linn via swift-evolution <swift-evolution@swift.org> wrote:

FKL

On Dec 10, 2015, at 10:09 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks for your suggestion!

But you're talking about the guidelines for Swift API Design while I'm proposing a keyword change in the language itself. I think they are not the same subjects.

From: sethfri@gmail.com <mailto:sethfri@gmail.com>
Date: Thu, 10 Dec 2015 18:58:45 -0800
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: feijian_sun@hotmail.com <mailto:feijian_sun@hotmail.com>; jackl@apple.com <mailto:jackl@apple.com>
CC: swift-evolution@swift.org <mailto:swift-evolution@swift.org>

I encourage you to read the Swift API Design Guidelines <https://swift.org/documentation/api-design-guidelines.html&gt;, as there are a couple of things there that discourage what you are suggesting:
"Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate."
Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms.
The intended meaning for any abbreviation you use should be easily found by a web search.
Thanks,
Seth

On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Thank you for responding so late!

I agree with you that "subs" is not very obvious for subscript. While learning swift, I have a feeling that it contains so many long words as the keywords, such as

fallthrough, dynamicType, associativity, convenience, nonmutating, precedence, etc..

I understand there is a need for clarity. But I think it's also important to keep a concise and simple naming style where it's possible.

Thanks again.

Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
From: jackl@apple.com <mailto:jackl@apple.com>
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org <mailto:swift-evolution@swift.org>
To: feijian_sun@hotmail.com <mailto:feijian_sun@hotmail.com>

It’s non-obvious to me that “subs” is short for subscript, whereas “init” and “func” have only one obvious expansion.

Jack
On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello,

I have a proposal to replace the long keyword "subscript" with the shorter version, "subs". The idea is to keep the concise naming style on the language keywords, like "init" and "func".

So, Instead of:

subscript(index: Int) -> Int {
        ... ...
}

we could simply do:

subs(index: Int) -> Int{
        ... ...
}

Does this mean a big change on the parser side? what do you think?

Thank you!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Just a comment here… tl;dr

It is unfortunate that people are not able/willing to read the clear goals of the project as outlined by its leadership and follow suite. This is the third or forth such request I’ve seen in a short period that has been proposed of which the only goal was to reduce typing by a few characters; which has been shown is not a goal of Swift.

It seems everybody is eager to propose “something” but these type of proposals seems to be generating a bit of chatter, on a list that is very active. As outsiders I think we really need to respect the goals and the demands a list like this puts on the leaderships time. We don’t want to disengage them with an overwhelming list of requests that are not really viable.

P.S. Yes I get the irony that I just created more “chatter” just thought somebody should point this out. Also, I would like to verify that I have no affiliation with the project, Apple or otherwise. Jut a concerned citizen that wants to make sure our up close and personal access to the leaders of this project remains intact.

···

On Dec 10, 2015, at 9:18 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2015, at 7:41 PM, Frederick Kellison-Linn via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The language itself uses many abbreviations as its keywords. If you search for 'var' on web, for example, you won't easily find it stands for 'variable'. Does it mean it violates the guidelines?

Actually, a Google search for just ‘var’ yields results pointing to JavaScript, C#, and HTML on the first page. A search for ‘init’ immediately describes the init process on Unix systems, as well as many other programming related results. Following any of these will let you understand the meaning of ‘init’ or ‘var’ pretty quickly. OTOH, ‘subs’ gives lots of results for sandwiches, but nothing programming related.

As a concert example of confusion that can arise, String implements subscript(), but ‘subs’ could just as easily stand for ‘substring’ in this context.

“var", “func", and “struct" are exceptions to the general rule because they’re so prominent; even novice Swift programmers will quickly learn these three concepts. “subscript” is probably at least three orders of magnitude less common, and many programmers will not be immediately familiar with it, so it’s far more important to be clear than succinct.

John.

FKL

On Dec 10, 2015, at 10:09 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks for your suggestion!

But you're talking about the guidelines for Swift API Design while I'm proposing a keyword change in the language itself. I think they are not the same subjects.

From: sethfri@gmail.com <mailto:sethfri@gmail.com>
Date: Thu, 10 Dec 2015 18:58:45 -0800
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: feijian_sun@hotmail.com <mailto:feijian_sun@hotmail.com>; jackl@apple.com <mailto:jackl@apple.com>
CC: swift-evolution@swift.org <mailto:swift-evolution@swift.org>

I encourage you to read the Swift API Design Guidelines <https://swift.org/documentation/api-design-guidelines.html&gt;, as there are a couple of things there that discourage what you are suggesting:
"Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate."
Avoid abbreviations. Abbreviations, especially non-standard ones, are effectively terms-of-art, because understanding depends on correctly translating them into their non-abbreviated forms.
The intended meaning for any abbreviation you use should be easily found by a web search.
Thanks,
Seth

On Thu, Dec 10, 2015 at 6:52 PM Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Thank you for responding so late!

I agree with you that "subs" is not very obvious for subscript. While learning swift, I have a feeling that it contains so many long words as the keywords, such as

fallthrough, dynamicType, associativity, convenience, nonmutating, precedence, etc..

I understand there is a need for clarity. But I think it's also important to keep a concise and simple naming style where it's possible.

Thanks again.

Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
From: jackl@apple.com <mailto:jackl@apple.com>
Date: Thu, 10 Dec 2015 18:22:55 -0800
CC: swift-evolution@swift.org <mailto:swift-evolution@swift.org>
To: feijian_sun@hotmail.com <mailto:feijian_sun@hotmail.com>

It’s non-obvious to me that “subs” is short for subscript, whereas “init” and “func” have only one obvious expansion.

Jack
On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello,

I have a proposal to replace the long keyword "subscript" with the shorter version, "subs". The idea is to keep the concise naming style on the language keywords, like "init" and "func".

So, Instead of:

subscript(index: Int) -> Int {
        ... ...
}

we could simply do:

subs(index: Int) -> Int{
        ... ...
}

Does this mean a big change on the parser side? what do you think?

Thank you!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution