[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library

[Dave Abrahams]

on Tue Feb 02 2016, Radosław Pietruszewski <swift-evolution at swift.org> wrote:

>> On 02 Feb 2016, at 02:41, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Mon Feb 01 2016, Janosch Hildebrand <swift-evolution at swift.org> wrote:
>
>> 
>>> I'm generally in favor of the proposed changes. I'll just note some
>>> minor points and disagreements:
>>> 
>>> * Like I mentioned in my SE-0023 review, I would be OK with keeping
>>> the "Type" suffix for protocols but have no strong preference.
>>> 
>>> * I'm in favor of keeping `precondition()`. `require()` might be
>>> easier to grasp at first but personally I really came to like
>>> `precondition()`.
>>> It fells both precise and I prefer the passive `precondition()` to the
>>> active `require()` for this case. To me it fits the primary meaning
>>> better; stating an API contract. The fact that the condition is
>>> actively checked is secondary to that.
>>> 
>>> * I also agree with Radosław in that I prefer `removeAll(keepCapacity:
>>> Bool)` to `removeAll(keepingCapacity: Bool)`.
>> 
>> Why?
>> 
>> I had a hard time justifying "keeping" to myself for a while, but
>> eventually I realized that this pattern is less ambiguous, at least in
>> general, since many verbs are also nouns.  Okay, "keeps" haven't been
>> considered high-tech construction elements since the middle ages, but
>> it's easy to understand how you'd be interested in the capacity of a
>> keep.
>
> Why not, though? adding `-ing`s in this context has all of the
> problems -ed/-ing has with method names, 

Which problems, sorry?

> and none of the necessity of conveying mutability information.
>
> What’s wrong with “keepCapacity” as a parameter name?

It can be interpreted as denoting the capacity of the keep.

>>> * What is the rationale for moving `unsafeUnwrap` into Optional but
>>> not `unsafeAddressOf` into AnyObject? 
>> 
>> Language limitation: AnyObject can't be modified or extended.
>> 
>>> I can certainly see the safety argument against moving it but I don't
>>> see how that would apply to `unsafeAddressOf` but not `unsafeUnwrap`?
>>> 
>>> * `EnumeratedSequence` and `Repeated` feel weird to me. They make
>>> sense given the API guidelines and the previous `EnumerateSequence`
>>> and `Repeat` were a bit clunky as well but these somehow feel a bit
>>> worse... That might be wholly subjective though and I don't really
>>> have a good suggestion. The only thing that came to mind was
>>> `EnumerationSequence` and `Repetition` but I'm not overly fond of
>>> those either especially not to the point of deviating from the norm...
>> 
>> Yes, they're a little clunky.  No, I don't have any better ideas either
>> :-)
>> 
>>> * This is not a disagreement but I'd be interested in hearing the
>>> reasons for replacing Generator(Type) with Iterator(Protocol) if
>>> someone finds the time. I can speculate of course but it's probably
>>> easier for someone to give me a short summary :-)
>> 
>> I think these messages give all the details:
>> 
>> http://news.gmane.org/find-root.php?message_id=m2h9i4gffx.fsf%40eno.apple.com
>> http://article.gmane.org/gmane.comp.lang.swift.evolution/5344
>> 
>>> * Typo: 
>>>> +  public func take() -> Memory // Should be Pointee
>> 
>> Nice, thanks.
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> 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