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

[Seth Friedman]

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 at 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 at 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 at hotmail.com; jackl at apple.com
> CC: swift-evolution at swift.org
>
>
> I encourage you to read the Swift API Design Guidelines
> <https://swift.org/documentation/api-design-guidelines.html>, 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 at 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 at apple.com
> Date: Thu, 10 Dec 2015 18:22:55 -0800
> CC: swift-evolution at swift.org
> To: feijian_sun at 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 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?
>
> Thank you!
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/da0bc27e/attachment.html>