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

Dave Abrahams dabrahams at apple.com
Mon Feb 1 19:41:21 CST 2016


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.

> * 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



More information about the swift-evolution mailing list