[swift-evolution] [Draft] Rename Sequence.elementsEqual

Adam Kemp adam.kemp at apple.com
Sun Oct 15 02:29:21 CDT 2017


I don’t think it’s impossible. I still think pairwiseEqual is clear and intuitive, and if sequenceEqual doesn’t work because of other conventions then maybe sequentiallyEqual could work. There have been several other proposed names as well. We should be spending more time discussing these alternatives.

What other names can we come up with? Let’s discuss them. 

> On Oct 14, 2017, at 11:18 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
>> On Sun, Oct 15, 2017 at 12:56 AM, Adam Kemp <adam.kemp at apple.com> wrote:
>> 
>> 
>> > On Oct 14, 2017, at 10:32 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> >
>> > Therefore, it is entirely OK (to me) if the result is something that is so obtuse as to be at first meaningless to most people.
>> 
>> I can’t speak for others, but it’s not ok with me. API is UX. It should be understandable and approachable. If this were a function that was considered dangerous and we wanted to discourage its use then maybe I could buy this argument, but I don’t think that’s quite the case here. Even if you don’t think it’s the best API to use or the most common it should still be named clearly.
> 
> I don't disagree with you that it should be _clear_. I'm simply wondering out loud whether it is possible to name this method _intuitively_ (i.e., clear without resorting to documentation) given that it lives in the nexus of an inherent contradiction between protocol and implementing type which is anything but intuitive (or even clear after you read the documentation).
> 
> If it is not possible to name this method _intuitively_, then it is not possible to name it _well_. Then, given the option between obtuse-but-correct and approachable-but-misleading, I would opt for the former as the _least bad_ option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171015/86f64a28/attachment.html>


More information about the swift-evolution mailing list