On Sun, Oct 15, 2017 at 1:18 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> On Sun, Oct 15, 2017 at 12:56 AM, Adam Kemp <adam.k...@apple.com> wrote: > >> >> >> > On Oct 14, 2017, at 10:32 PM, Xiaodi Wu <xiaodi...@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. > Hmm, I do think I can squash some of these suggestions into an explicit and very clear option: equalsInIterationOrder(_:) We would then clarify the corresponding precedence function in the same way: lexicographicallyPrecedesInIterationOrder(_:) (Lexicographic precedence in contradistinction to length-lexicographic or Kleene-Brouwer precedence.) All other "order-dependent" functions, as Apple documentation calls them, on Set and Dictionary are pretty explicit about being intrinsically order-dependent (in that they talk about firsts, lasts, starts, ends, prefixes, suffixes, indices, ranges, dropping, popping, reversing, joining, or splitting).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
