[swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Dave Abrahams]

on Mon Jul 25 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

>> 
>> 	* What is your evaluation of the proposal?
>
> I was not totally happy with early drafts of this proposal.  The final
> draft is a significant improvement.  I am mostly +1, with a couple of
> minor critiques.
>
> I think this proposal pushes a bit too hard on consistency of “first /
> last” vs “prefix / suffix”.  Specifically, I think first(n) and
> last(n) are significantly more clear than prefix(n) and suffix(n) (and
> removingFirst(n) / removingLast(n) instead of removingPrefix(n) /
> removingSuffix(n).  I think the former are immediately clear.  The
> latter, while consistent in terms of matching semantics with a naming
> convention suffer in terms of clarity at the call site.  I do not
> think it is immediately clear that the parameter specifies the
> *length* of the prefix or suffix.  

+1, and it doesn't: it specifies the *maximum length*.

> removingPrefix(ofLength: n) would solve the clarity issue at the
> expense of verbosity.  I would prefer we just keep first / last in
> these cases.
>
> Another comment is that you have generally moved index based methods
> to subscripts rather than named methods.  Why didn’t you take this all
> the way and change `replaceSubrange` to be a subscript setter?

The language doesn't allow it:

1. replaceSubrange is generic on the sequence argument and we don't have
   generic subscript

2. you'd need to have a matching subscript getter, and there would be no
   way to deduce the result in most cases, potentially causing
   ambiguity.  I dunno, maybe this could work, but we'd need to solve
   problem 1 before we could find out.


>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
>
> Yes, the new names have more consistency.
>
>> 	* Does this proposal fit well with the feel and direction of Swift?
>
> Yes.
>
>> 	* If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>
> I don’t believed I have used any languages that emphasize consistent
> naming and API guidelines as strongly as Swift.  This is a good
> direction.
>
>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> A relatively quick read.
>
>> 
>> More information about the Swift evolution process is available at
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> 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