[swift-evolution] API Guidelines Update

[Dave Abrahams]

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,

      x.expanded()

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?
> etc.
>
> 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
determination.

> — Taras
>
>> 
>>> so there might be some cases where it's easy to confuse Bool
>>> properties with non-Bools.
>> 
>> I don't get it; sorry...
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> 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>

-- 
-Dave