[swift-evolution] API Guidelines Update
crk at akkyra.com
Thu Feb 18 10:42:36 CST 2016
My simple, non-linguist’s interpretation of the objections raised by Taras and others is that the “-ing” names might be strictly grammatical but they aren’t common usage, and for that reason they often don’t feel right. To reference a famous movie quote, nobody would say: “Leave the gun, taking the cannolis”. It’s not how people speak or write.
Using your example: “Give me the list of all students, removing those who got As”, nobody would say that either. They would say: “Give me the list of students who didn’t get As.”
I suppose another way of saying it is that these “-ing” forms sound stilted (with “unioning” being the poster child for that). I’m not arguing the importance of this objection, just that I understand it and think it’s valid.
My own way of avoiding many of these “-ing”s is to use a static method for the non-mutating form:
let z = Mytype.add(x, y)
> On Feb 17, 2016, at 11:37 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> on Wed Feb 17 2016, Taras Zakharko <taras.zakharko-AT-uzh.ch> wrote:
>>> On 18 Feb 2016, at 06:44, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>> Also, you could infer "x.expanding..." alone to mean "x, *by*
>>>> expanding..." or "*whether *x *is* expanding...",
>>> Only by adding words that aren't there.
>> I think what Jacob is trying to say is that an ‘-ing’ form does not
>> have a clearly defined semantics in English. Depending on the
>> construction, the meaning can differ. This creates potential
>> confusion, as many people have pointed out earlier. Taking
>> x.expanding() again,
> It's a bad example, because the guidelines say to prefer “ed” unless it
> would be ungrammatical. In this case,
> is clearly grammatical, so you never end up here in the first place
>> it is clear that guidelines intend an irrealis reading ‘if x were
>> expanded, it would be’ or a resultative reading ‘x,after it has been
>> expanded’. However, this is NOT a very typical reading associated with
>> -ing forms. In particular, other, more conventional readings include:
>> - converb construction (x is standing there, expanding)
>> - atelic action/focus on a subprocess (x is expanding)
>> - statement about a quality (x is expanding = x is of a quality that it is an expanding one)
>> - question, by modifying prosody: (is x ) expanding?
>> I believe that it is somewhat unfortunate that the guidelines
>> (correctly, IMO) promote verbosity over luck of clarity and then at
>> the same time introduce semantically obscure or outright weird notions
>> based on the ‘-ing’ forms. Something like ‘x.havingAdded(e)’
>> communicates the intent much better than ‘x.adding(e)’ (which reads
>> like a notification), and yet more clear is ‘concatenate(x, e)’.
> The problem is that if you use x.add/x.havingAdded as a standard
> convention, you end up with gobs of methods that start with “having,”
> which tends to break up the association between the mutating and
> non-mutating forms. We think that association is important.
>> So going back to ‘adding words that aren’t there’ — by promoting this
>> guideline rule, you are already doing this.
> Doing what?
> (“this” without an antecedent; tsk, tsk --- yes, I'm well aware that
> correcting a linguist's writing is very likely to backfire, but I
> couldn't resist)
>> But I digress. As a linguist, I am not very fond of this aspect of the
>> guidelines, but if they are applied consistently, people will get used
>> to them. Just don’t make a mistake and believe they are ‘grammatical’
>> — they are not,
> That's quite a claim. I previously understood you to be saying that the
> forms weren't typical usage, but are you really saying that “Give me the
> list of all students, removing those who got As” is ungrammatical?
>> they are creating new conventional readings which are fairly untypical
>> under normal language use.
> Take out the "creating new" part and that is a completely separate issue
> from grammaticality. I would be very surprised if we were actually
> inventing new grammar here, especially because these guidelines were
> checked by a (different) linguist. If you really mean that, I'll try to
> put the two of you in touch so you can duke it out and we'll get a
>> — Taras
>>>> so there might be some cases where it's easy to confuse Bool
>>>> properties with non-Bools.
>>> I don't get it; sorry...
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution