[swift-evolution] [Review] SE-0023 API Design Guidelines

[Dave Abrahams]

on Fri Jan 22 2016, Thomas Visser <swift-evolution at swift.org> wrote:

>> Uses of non-mutating methods should read as noun phrases when possible, e.g. x.distanceTo(y), i.successor().
>> 
>
> This seems to indicate (to me) that e.g. Optional.map and should be
> renamed to Optional.mapped? Except that ‘map’ in this case could be
> considered a ’term of art’. 

Yes, that's the rationale for keeping names like “map” and “flatMap” as
they are.

> Would it make sense to add to add some kind of guidance on how to
> weigh the individual guidelines when they are conflicting?

I don't think so.  First, I think it's probably impossible to come up
with good guidance for that; at some point it's a matter of using
judgement.  Second, we want to keep the guidelines as simple as
possible, so they're easy to follow.

>
> Thomas
>
>> On 22 Jan 2016, at 22:02, Douglas Gregor via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0023"API Design Guidelines" begins now and runs
>> through January 31, 2016. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md>
>> Reviews are an important part of the Swift evolution process. All
>> reviews should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> or, if you would like to keep your feedback private, directly to the
>> review manager. When replying, please try to keep the proposal link
>> at the top of the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md>
>> Reply text
>> 
>> Other replies
>>  <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under
>> review through constructive criticism and, eventually, determine the
>> direction of Swift. When writing your review, here are some
>> questions you might want to answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>> Thank you,
>> 
>> -Doug Gregor
>> 
>> Review Manager
>> 
>> _______________________________________________
>> 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

-- 
-Dave