[swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"

Feijian Sun feijian_sun at hotmail.com
Fri Dec 11 07:52:51 CST 2015

Interesting idea and I like it myself.
My idea of shortening the long keywords in swift came up when I was typing swift code using a simple text editor. Without the help from the auto-complete feature in xcode, I was really feeling the pain. Considering that the swift has been port to linux platforms and many developers now have chances to code swift with none-xcode editors on linux, they could feel the same pain like I did.
But I see Chris's points in his response email. Following the 3 point approach to keywords, it's clear that we should keep "subscript".

From: ilya.nikokoshev at gmail.com
Date: Fri, 11 Dec 2015 12:18:26 +0000
Subject: Re: [swift-evolution] Proposal for Replacing Keyword "subscript" with "subs"
To: clattner at apple.com; feijian_sun at hotmail.com
CC: swift-evolution at swift.org

Functional programming style brings us a lot of joy, so the most important keyword shortening to support is obviously func -> fun. 
On Fri, Dec 11, 2015 at 08:06 Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
On Dec 10, 2015, at 6:12 PM, Feijian Sun via swift-evolution <swift-evolution at 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?
Hi Feijian,
I agree with Jack in this case that we should keep "subscript".  Swift's rough approach to keywords is: 
1) reuse contracted keywords that are widely known in the C family when the connotations are obvious (e.g. struct, enum, etc).  2) contract some “new” keywords for the *most commonly occurring* situations (e.g. func/var, though var is precedented in a number of extended c family languages like javascript), because people are expected to be forced to learn these things in the first few days of their swift learning.3) otherwise, use a full word (subscript, convenience, mutating, etc).
In the case of subscript, it doesn’t occur often enough to be worth forcing people to memorize, and thus we prefer obvious clarity in the situations when it occurs in code.


swift-evolution mailing list

swift-evolution at swift.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/c9f85485/attachment.html>

More information about the swift-evolution mailing list