[swift-evolution] Inconsistencies related to prepositions

[Xiaodi Wu]

On Wed, Aug 2, 2017 at 5:48 PM, Mike Sanderson <m at mikesand.com> wrote:

>
> On Wed, Aug 2, 2017 at 1:49 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> ...
>>
>> This topic was reviewed extensively at the beginning of Swift Evolution.
>> The idea is that type information does not need to be repeated in the
>> label. Since the locale is of type Locale, “with” is preferred over
>> “withLocale” because “withLocale: Locale” is redundant. As this has been
>> long approved by the community, it’s not in scope to roll it back.
>>
>
> Thanks to everyone who contributed to the list to make the Swift 3 API
> guidelines possible. I think the Swift 3 API Guidelines were a tremendous
> accomplishment, and I appreciate the actual beauty that can result from its
> sparse code.
>
> It seems reasonable that 1 1/2 years after the proposal, more than 1 year
> after beta release, and after seeing the API Guidelines applied out in the
> world (or not) and applying them ourselves (or not), to bring up the
> subject again and ask if it can be improved. I think Jon gave some good
> examples of weaknesses that can result, and Robert gave some good
> suggestions.
>
> Changing existing code is probably out of scope to avoid language
> churn--and it definitely would contradict Swift 4's goal of preserving
> source stability. The Great Re-Renaming? No thanks. (Thought I think The
> Great Renaming unfairly got the blame for later migration issues.)  Still,
> these messages today were substantive suggestions for how to improve Swift
> API naming conventions. I am re-reading the threads from Jan and Feb 2016,
> which seems appropriate to inform a discussion that builds on them, but it
> would be weird to regard those conversations as a reason to shut down any
> mention of the subject ever again. This seems like exactly the kind of
> subject that should be revisited, and could form a proposal later in the
> fall.
>
> As someone who admires the API guidelines and how they make Swift read
> elegantly, I want to make them even better and easier to use. I myself
> think that the English language is too ungainly to support rules for a
> language as elegant as Swift. So I hope we can continue to have this
> conversation.
>

There is a difficult balance to strike here, to be sure. On the one hand,
Jon has written a very thorough analysis of some pros and cons of Swift's
API guidelines and their real-world implementation. On the other hand,
while the analysis is substantive, unfortunately it does not tread new
ground in terms of what has already been discussed on the list. The
trade-offs and alternatives discussed today *were* studied at the time of
the adoption of these guidelines, and as with any decision to do with
naming, not everyone agreed with all the points. Nonetheless, a decision
was made. Moreover, of Jon's five examples, one is actually not a renaming
at all, one renaming was explicitly approved (with its own special rule),
and the remainder are Apple APIs not subject to Swift Evolution. (I agree
that `timeIntervalSince` seems to be contrary to Swift naming guidelines,
but we don't get to name that API as a community.)

I also disagree very strongly that 1.5 years after a proposal is an
appropriate time to revisit a tentpole feature of a previous release. This
was a major undertaking that occupied the attention of all for a very long
time. There is an interval between 1.5 years and ever again for bringing up
past decisions: as idiomatic Swift grows with time, there may certainly
come a time to revise guidelines laid down for Swift 3. But I strenuously
disagree that Swift 5 is an acceptable timeframe for revising this effort.
The most contentious disagreements on this list have been API renaming and
access control modifiers; the latter is now different for each of Swift 2,
3, and 4. These efforts had costs in terms of time and energy (and likely
took an emotional toll too) on participants. It is not at all "weird" to
regard those conversations as a reason not to continue the conversation; in
fact, based on that experience, I believe strongly that we would
*certainly* be better off as a community by not rehashing API names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/9f431171/attachment.html>