surface area and leverages the user's understanding of how ranges
work.
It also implies we can replace
x.removingPrefix(n)
x.removingSuffix(n)
with
x[$+n..<]
x[..<$-n]
for Collections.
I'm not enamored of this suggestion. It succeeds in reducing API surface
area, but at a severe cost to readability. You'd replace an unambiguous
phrase (removing prefix or suffix), the meaning of which is further
clarified by the consistent usage proposed in SE-0132, with a wordless
spelling using some combination of [$+.<]. Cognitively, also, it
substantially increases the burden for the reader: it replaces a single
argument with a nested series of arguments; first, one must understand the
meaning of the $ placeholder, then one must consider an addition or
subtraction operation, then the formation of a range, and in the last
example, the use of that range as a subscript argument--again, all
wordlessly. Finally, subscripts have so far not been "forgiving," while
today's `dropLast` very much is; this suggestion would add inconsistency by
using a subscript for a forgiving or "lenient" operation.
I second Xiaodi. I am against the slicing subscripts and the ones above
look even more unreadable and inscrutable than those in the proposal. I
don't understand the rational.
Neat. However, $+n and $-n remain problematic for me, one additional reason
being that these suggest indices move themselves, which they no longer do
in Swift 3. Of course, we could (and, in fact, we would have to) say that
$+n is short for `x.index(x.startIndex, offsetBy: n)`, but that'd be a
pretty big contortion for the + operator.
···
On Tue, Jul 26, 2016 at 2:01 AM, Daniel Duan <daniel@duan.org> wrote:
On Jul 25, 2016, at 11:32 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:
On 26 Jul 2016, at 06:50, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
Whoops, hit reply too soon. Please consider the following inserted in the
gap in my last email:
2. We're not comfortable with heavily overloading a property with a bunch
of methods, and didn't want to make `first` and `last` into methods.
I am okay with this overload precisely *because* the functionality is so
similar.
3. Most APIs work fine, but `hasFirst(_:)` is atrocious, and we see no
better alternative which includes the word `first`.
Agreed. Both `starts(with:)` or `hasPrefix(_:)` are much better, and I
would be happy with either.
…and I seem to have cut off a sentence at the end of my last email:
Something like `prefix(limit: n)` is more descriptive than the bare
`prefix(n)` form, however in my view it still falls short of clarity
achieved by `first(n)`.
Nevin
···
On Tue, Jul 26, 2016 at 7:16 PM, Nevin Brackett-Rozinsky < nevin.brackettrozinsky@gmail.com> wrote:
* We considered using `first` and `last` as the basis for both
single-element and multiple-element operations (such that `prefix(3)`
would become `first(3)`, etc.), but:
1. These seemed like distinct functionalities, particularly since
their types are different.
I think the functionality of “Please give me the first 1 element” is
extremely similar to “Please give me the first n elements”.
Keeping those issues in mind, do you still prefer `first(n)` over
`prefix(n)`?
In my subjective opinion, `.first`, `.first(n)`, and `starts(with: [1, 2,
3])` are crystal-clear at the use site, and coexist just fine.
Additionally, `hasPrefix([1, 2, 3])` is equally clear and I would be fine
with that—in particular I am fine with the “get” and “test” methods using
different words.
By contrast, I find `prefix(n)` to be unclear about the role of `n`.
Something like `prefix(limit: n)`
On Tue, Jul 26, 2016 at 3:46 PM, Brent Royal-Gordon < > brent@architechies.com> wrote:
> On Jul 26, 2016, at 8:30 AM, Nevin Brackett-Rozinsky < >> nevin.brackettrozinsky@gmail.com> wrote:
>
> However, I believe that `first(n)` and `last(n)` read more clearly at
the point of use than `prefix(n)` and `suffix(n)`.
I've seen this a couple of times. It's something I bring up in "Other
alternatives":
> * We considered using `first` and `last` as the basis for both
> single-element and multiple-element operations (such that `prefix(3)`
> would become `first(3)`, etc.), but:
>
> 1. These seemed like distinct functionalities, particularly since
> their types are different.
>
> 2. We're not comfortable with heavily overloading a property with a
> bunch of methods, and didn't want to make `first` and `last` into
> methods.
>
> 3. Most APIs work fine, but `hasFirst(_:)` is atrocious, and we see
> no better alternative which includes the word `first`.
the single word “first” only means one element，
but “prefix” can means multiple element.
I dispute the former claim. As evidence I cite:
• The first four letters of the alphabet are A, B, C, and D.
• The first three Presidents of the United States were George Washington,
John Adams, and Thomas Jefferson.
• The first two humans to walk on the moon were Neil Armstrong and Buzz
Aldrin.
The defense rests.
Nevin
···
On Tue, Jul 26, 2016 at 6:58 PM, Boris Wang <kona.ming@gmail.com> wrote:
Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>于2016年7月27日
周三03:46写道：
> On Jul 26, 2016, at 8:30 AM, Nevin Brackett-Rozinsky < >> nevin.brackettrozinsky@gmail.com> wrote:
>
> However, I believe that `first(n)` and `last(n)` read more clearly at
the point of use than `prefix(n)` and `suffix(n)`.
I've seen this a couple of times. It's something I bring up in "Other
alternatives":
> * We considered using `first` and `last` as the basis for both
> single-element and multiple-element operations (such that `prefix(3)`
> would become `first(3)`, etc.), but:
>
> 1. These seemed like distinct functionalities, particularly since
> their types are different.
>
> 2. We're not comfortable with heavily overloading a property with a
> bunch of methods, and didn't want to make `first` and `last` into
> methods.
>
> 3. Most APIs work fine, but `hasFirst(_:)` is atrocious, and we see
> no better alternative which includes the word `first`.
(The latter "test and merge" is failing for some reason).
-- Ben
···
On 26 Jul 2016, at 16:15, Dave Abrahams wrote:
b. they are given a recognizable domain-specific notation such as:
x.removeSubrange($+n..<)
x.removeSubrange(..<$-n)
Does $ represent the start, the end, or either one depending on which
side of the range we're on? Because if it's the third option, I think
these two operations are actually inverted: the first is removing
everything *except* the `prefix(n)`, and the second is removing
everything except the `suffix(n)`.
Wow, that was impressive! With one stroke, you have just convinced me
that we can't do this. The fact that I got it wrong, along with other
excellent feedback in this thread, kills my interest in using $ in this
way.
I'm working on an implementation (so far I just have `dropFirst` renamed, but I've only spent about half an hour on it, mostly waiting for tests), but the diff isn't really going to tell you much.
Just a quick peek, what's your first impression for
some.first(n)
Opt 1: the first element, who's value == n
Opt 2: the elements, who's index less than n
Neither.
It is asking for, quite specifically, the first n elements.
Nevin
···
On Tue, Jul 26, 2016 at 7:56 PM, Boris Wang via swift-evolution < swift-evolution@swift.org> wrote:
Ben Rimmington via swift-evolution <swift-evolution@swift.org>于2016年7月27日
周三07:29写道：
> On 26 Jul 2016, at 16:15, Dave Abrahams wrote:
>
>>> b. they are given a recognizable domain-specific notation such as:
>>>
>>> x.removeSubrange($+n..<)
>>> x.removeSubrange(..<$-n)
>>
>> Does $ represent the start, the end, or either one depending on which
>> side of the range we're on? Because if it's the third option, I think
>> these two operations are actually inverted: the first is removing
>> everything *except* the `prefix(n)`, and the second is removing
>> everything except the `suffix(n)`.
>
> Wow, that was impressive! With one stroke, you have just convinced me
> that we can't do this. The fact that I got it wrong, along with other
> excellent feedback in this thread, kills my interest in using $ in this
> way.
This would also conflict with one of the following:
We should consider SE-0111.
The label of parameter is not part of function signature anymore.
Just a quick peek, what's your first impression for
some.first(n)
Opt 1: the first element, who's value == n
Opt 2: the elements, who's index less than n
Ben Rimmington via swift-evolution <swift-evolution@swift.org>于2016年7月27日
周三07:29写道：
···
> On 26 Jul 2016, at 16:15, Dave Abrahams wrote:
>
>>> b. they are given a recognizable domain-specific notation such as:
>>>
>>> x.removeSubrange($+n..<)
>>> x.removeSubrange(..<$-n)
>>
>> Does $ represent the start, the end, or either one depending on which
>> side of the range we're on? Because if it's the third option, I think
>> these two operations are actually inverted: the first is removing
>> everything *except* the `prefix(n)`, and the second is removing
>> everything except the `suffix(n)`.
>
> Wow, that was impressive! With one stroke, you have just convinced me
> that we can't do this. The fact that I got it wrong, along with other
> excellent feedback in this thread, kills my interest in using $ in this
> way.
This would also conflict with one of the following: