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

[ilya]

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.
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/2036d4fc/attachment.html>