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

[Garth Snyder]

A warm -0.5 from me, meaning that I agree that this issue is important to address, and that I concur with many of the particulars. (I agree that removing is way better than drop, for example.)

However, I suspect that this approach may open more Pandora’s boxes than it closes. Most of my discomfort centers on the idea of incomplete ranges. This seems like a major thing to introduce to the language, and although I like the concept, it raises questions that deserve to be addressed independently. Incomplete ranges shouldn’t be allowed to just sneak in the back door as part of an API cleanup in one particular area.

Really, it seems like ranges could do with some attention in their own right. In their current form, they feel like largely pragmatic constructions that aren't yet fully baked. A lot of elaborations have already been piled onto them, and they’re responsible for a lot of API-level complexity. But as yet, they’re not capable of representing, e.g., intervals that are open or half-open on the left. 

Incomplete ranges seem to push the idea of ranges even further in the direction of abstract predicates or mathematically general models of intervals. For example, SE-0132 suggests

    ..< 3

as a syntax for an upper-bounded range. But wouldn’t 

   < 3

be a more natural syntax for this? From a logical perspective, you’re not really creating a range so much as expressing the condition that something is less than 3, which happens to be encoded by a range. If we had incomplete ranges, wouldn’t you want to be able to use them naturally in, e.g., case statements?

    switch (value) {
        case < 3: 
            // Small value
        case 3…5:
            // Medium value
        case > 5:
            // Large value
    }

Doesn’t it seem odd that < 3 is representable as a range but > 5 is not? 

(I’ve shown all these with reasonable spacing, but IIRC, the odd no-space-around-range-operators rule is still in effect. That would be worth addressing, too, if ranges are really going to be first-class citizens.)

> Matthew Johnson: 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.


Agreed. According to the API standards, a method removePrefix() seem like it should accept a prefix as an argument.

> Matthew Johnson: 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?

That’s a good point also.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A complete reading of the proposal, but without existing knowledge of the subtleties of Range implementation.

Garth