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

[Dave Abrahams]

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

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

I don't view it as a sneak.  They'd be hard to justify adding without
APIs that use them, so I don't see them coming in as a separate
proposal.

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

They're as baked as the current language definition makes practical.

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

Because we don't have important use-cases for those.  The ranges that we
do have serve important roles.  Just as we wouldn't add incomplete
ranges without APIs to go with them, we also wouldn't add
open-on-the-left ranges if they didn't have an important role to play in
the standard library or common user programs.

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

Not really; it's a range *expression*, that's intended to be reified
with respect to a collection.

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

Interesting idea, but it seems like it opens a whole can of complexity.
As a consequence, are we talking about supporting a[% 2 == 0] to get the
even-numbered elements of an array?

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

These range expressions are not intended to stand alone.

> (I’ve shown all these with reasonable spacing, but IIRC, the odd
> no-space-around-range-operators rule is still in effect. 

There's no rule, just convention.

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

Actually not.  The API guidelines say that if the thing can function as
a direct object of the verb, you don't put a noun before it.  That would
be

    x.remove(somePrefix)

>> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave