[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices
dabrahams at apple.com
Mon Apr 18 16:57:04 CDT 2016
on Sun Apr 17 2016, Thorsten Seitz <swift-evolution at swift.org> wrote:
> The nonmutating forms successor/predecessor were fine. No need to
> match them with the mutating ones IMO.
Our API guidelines say that we should match them. We should have a
better reason to depart from the API guidelines than “some people don't
like the results in this case.” And if the guidelines are inadequate
for handling cases like this, we should fix them.
>> Am 13.04.2016 um 21:57 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org>:
>> on Wed Apr 13 2016, Dave Abrahams <swift-evolution at swift.org> wrote:
>>>> Reverse is the best opposite we have of advance, so it makes sense to
>>> Oh, I get it.
>>>> Or we could use retreat. =) There are other pairs of words that work
>>>> as well, like “increment/decrement”.
>>> Yeah, unfortunately those carry an incorrect implication when the
>>> indices are numbers, because, e.g. the collection might be offsetting
>>> the number by 2 for each position. One could of course argue that using
>>> numbers that way as indices was a bad design choice.
>>> I'll have to think about that idea again. We considered and rejected it
>>> for a reason, but it might not be a really strong one. Thanks for
>>> bringing it up.
>> ...and having talked it over at lunch, now I remember why we rejected
>> it: there's no good way to make a nonmutating version.
>> let x = c.incremented(i) // reads like an assertion about the past
>> let y = c.incrementing(i) // reads like it has side-effects and returns c, or
>> // a new version of c
>> APIs where the receiver returns a modified version of an argument don't
>> lend themselves to verb forms.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution