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

[Howard Lovatt]

Keeping capacity is definitely better English, but it is a minor point
since a collection doesn't have a keep and therefore no confusion.

On Wednesday, 3 February 2016, Radosław Pietruszewski <
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?
>
>
> A bit of extra spelling gymnastics… Maybe I’m the only one bothered by
> this, but I’d just prefer a shorter/simpler name in absence of a compelling
> reason to do otherwise. (You did make an argument for why in a later post,
> fwiw. I’m not super compelled by it, but also don’t feel so strongly
> against the `ing` to argue further ;) )
>
>
> 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.
>
>
> Wow, that… would have never crossed my mind ;)
>
>
> * 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
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>

-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/f9bae834/attachment.html>