I am not; as I have said on the list, there is one prime directive of naming: optimize for comprehensibility at the site of use.
To the degree that comprehensibility is subjective, we need to use some objective criteria to break ties. Surface uniformity, although secondary to comprehensibility, is valuable, as people tune into and take clues from trivial patterns of naming when they occur. One of the patterns that we have tried to maintain uniformly across the APIs (including all of Cocoa, with varying rates of success) is the pattern by which usage that forms an English phrase is broken into base name and argument labels.
My personal aesthetic preference for one form or other is not a sufficient reason to break uniform patterns that exist across the APIs. Therefore, I was hoping to find some patterns—that are precedented in our APIs for good reason, but not captured by the API guidelines—that would justify making the choice I preferred.
I don’t think that’s an fruitful direction. To illustrate: I’ve been told several times that for a non-native speaker, my command of English language is above average. But reading the above quote, I had to look up dictionary definition of preposition, to understand what you meant. I’m still not sure I fully grasp your point. People very rarely perform grammar analysis in everyday life. When using a language, we go by our gut feeling and say or write what feels natural, without thorough consideration of all the formal rules. This applies to the use of English and programming languages alike.
You seem to be looking for some kind of amendment to the API naming guidelines that would ground naming decisions in a set of English-grammar-based rules.
Such “rules” already exist in the guidelines, as one factor among many, and are a fundamental part of how they work. Developing those guidelines was a year-long process, driven by more than five people, aimed at creating uniform patterns across the standard library and Cocoa, which included repeatedly refining automated grammar-based translation of Objective-C APIs into Swift APIs, examining the resulting code to see how readable it was. The use of grammar, among other factors, to make naming decisions is not something anyone involved is eager to relitigate, and is too late to change without creating jarring nonuniformity or breaking vast amounts of code.
This approach might have been useful during the big rename, when performing automated conversions form the corpus of Objective-C method names. Even then I recall a linguist pointing out to you that English is inconsistent and shouldn’t be treated like a ruleset.
I went back and re-read that thread, and I don't understand that to be his point. His objection appears to turn on a broad understanding of what “grammatical” means. When we talk about grammaticality in the guidelines, we mean what I think most people understand it to mean, which Taras calls following “the conventional rules of morphology/syntax of English.” The “semantics and pragmatics” part of what Taras calls “grammatical” are covered by simpler and more prominent guidelines.
From Java I remember quite prevalent rule for naming Boolean variables and methods using prefix “is”. From my experience of striving for fluent interface, I find that dogmatic adherence to such simplistic rules actually hinders readability at the point of use.
I was and continue to be among the strongest advocates for the idea that surface uniformity is never the primary goal. I am constantly telling people that we don't have a goal to put "is" before every Bool or "where:" before every predicate.
The clarity is achieved by considerate construction of a domain specific vocabulary that slots in naturally into the shape provided by used framework. It’s a result of responsible application of judgment, not automated rules.
I'm quite certain nobody ever proposed that good names would be derivable from automated rules.
Regarding the question from core team about the weighing choices of the different argument labels, the above argument logically leads to choosing the 3rd option,
studentBody.containsOnly(gradeIsAPlus):
SE-0207: Add a containsOnly algorithm to Sequence
The main argument for #3 is that usage is still quite clear, and it would be better not to try to achieve grammaticality than to go partway there but fail (as in #1).On the other hand I fully support the concise term-of-art based name
.all(satisfy:), including the clarifying argument label. I don’t think we should be going for rule based guideline amendment to justify this choice.The over-reliance on English grammar creates accessibility barrier for non-native speakers. There’s something wrong when I need to consult dictionary to write Swifty code.
I am a native speaker, and I consult dictionary definitions constantly when trying to choose good names for things, FWIW.
The few prescriptive rules we currently have in the guidelines do go a long way and I fully support them. Extending them further with references to arcane English-grammar minutia isn’t really helping and as a second degree effect it creates a justification for bikeshedding, fueling unhelpful forms of pedantry and aggressive lawyering during naming discussions. In spirit of the essay “What Is ‘Correct’ Language?”, I hope we will reconsider the prescriptivist approach. If an amendment to guidelines is really necessary, I hope we can describe how to strive for fluency by adding more illustrative examples.
I argue for going with even lighter touch: de-emphasize the grammar reference in the guidelines.
Grammaticality is not, and never was, a goal in itself. The guidelines have one fairly gentle directive, to “prefer method and function names that make use sites form grammatical English phrases,” and then several prescriptions for the details when APIs are designed to read grammatically. The intention is that all of the guidelines are weighed, and where they conflict, judgement is used to prioritize them. I'm sorry, but I disagree that any change in emphasis is warranted.