+1
As my "a set isn't a sequence" rambling didn't even receive a single "yes we know but" response ;-):
4 Likes
I thought of these while reading the proposal and came here to find that they had already been posted, so they are natural to me at least.
Method name elementsEqual looks reasonable on Sequence but gets outright misleading, when used on concrete types. The problem is lessened post Swift 4.1 by conditional conformances for Sets of Equatable elements that gives you ==. But to me, the proposed five word method name represents the worst of excessively literal Cocoa naming, which doesn’t feel Swifty at all. sequentiallyEqual proposed up-thread is much better. That name was even proposed in 4th reply to the original discussion thread. My search there hasn’t revealed any valid counter argument against that name other than preoccupation with lexicographicallyEqual, which isn’t part of the updated proposal we vote on…
1 Like
As quoted in the proposal text, @Michael_Ilseman wrote a detailed explanation distinguishing between equality of sequences and equality of sequence elements. The method we are discussing here has to do with the latter. The names sequentiallyEquals or sequenceEquals erase the word "elements" and, in so doing, erase the distinction from the name; in fact, it is hard to imagine a name more similar to Sequence.== than sequenceEquals.
Swift's naming guidelines promote clarity at the point of the use; the name can be shorter if that improves clarity, or it can be longer if that improves clarity. For example, we have FloatingPoint.isTotallyOrdered(belowOrEqualTo:). In this case, we have empiric evidence that elementsEqual is insufficiently clear in real-world use; the revised proposal here entirely abandons my initially pitched name and instead addresses each of the demands that surfaced during the pitch phase:
-
It states that the method evaluates equality of the sequences' elements and not of sequences (by preserving the words "elements equal"--note the verb agreement with the plural noun).
-
It clearly states that the method is order-dependent (by explicitly using the word "order").
-
It clearly states in what order the comparison is made in a way that cannot be interpreted as first sorting and then comparing (by using the phrase "in iteration order").
All of these points were raised by the community during the pitch phase and the resulting proposal reflects the result of that process.
+1 on the proposal in general, the current name can definitely be confusing.
I'm not in love with the name though, it describes clearly what is happening but feels unnecessarily verbose.
I feel like with the correct wording the latter two are kind of redundant. Have you considered elementsAndOrderEqual? It mentions both, and the order of the words (
) seems to make it clear to me that no reordering is involved.
If we can't find a better name, I'd rather have elementsEqualInIterationOrder than not changing anything though.
1 Like
I don't feel strongly about this proposal, here are my lightly held opinions:
I recognize that the current name isn't ideal, but I feel that the motivation is very weak.
As Ole mentioned upthread, the major reason that this was causing active harm was that sets were not equatable (prior to Swift 4.1). That bug was fixed, so people won't be as driven to the footgun nearly as much anymore. What is the remaining strong motivation that makes it worth dealing with the source compatibility issues?
This is the big open question to me. I agree that the new name (or something close to it) is better, but it isn't clear to me that the problem is significant enough to meet the bar for introducing a change. I tend to lead weakly towards "no, it isn't worth it to fix at this point".
Yes. A long and verbose name is the right thing to do for such a weird and infrequently used method, particularly one that can have surprising behavior in generic code. Now that we have conditional conformances, most people will just be happy with == and !=.
Very little effort, and more to the point, I haven't done a study of real world code, and how/when it uses elementsEqual. If there were a large number of uses of it that ca't be converted to ==/!=, then maybe this is more important than it seems.
-Chris
3 Likes
It seems to address a real concern of clarity, but the solution is a bit verbose. Maybe something like seq1.isIsomorphic(to: seq2) might be easier to type for people trying Swift on platforms without IDE support.
Possibly: The proposed fix does remove any confusion.
No, extra long method signatures seem very Objective-C like.
N/A
I gave it a quick reading.
-1, because...
No, I don't think the problem is large enough to warrant a source-breaking change at this point. This seems, to me, something that should be addressed by documentation and perhaps linter-like tools.
Doug
1 Like
Can you think of a concrete example where sequentiallyEquals is misleading? I can't, and I remain convinced that this is the best name for this API. The use of "sequentially" accurately describes the behavior and aligns well with both Swift's concept of a sequence as well as the general English definition. It also has the bonus of being relatively concise. I don't see the inclusion of the term "elements" as a requirement -- I don't think it's necessary if we use the term "sequentially". If a type is considered a sequence and something is done to it sequentially, it should be totally clear that it is in terms of its sequence of elements.
5 Likes
If you buy the argument that we must distinguish between equality of two sequences versus equality of their elements, then it's hard to see how renaming the method by removing the word "elements" and inserting the word "sequentially" is moving in the right direction in terms of clarity.
If this method is worth renaming at all because of a lack of clarity, then it's worth naming in a way that is surpassingly clear. Being concise is not a bonus; I agree with Chris here that, if the problem is significant enough to warrant a source-breaking change, then "a long and verbose name is the right thing to do."
I agree that removing “elements” makes the meaning of this function less clear.
With that in mind, what do you think of my suggestion, elementsSequentiallyEqual? I think it hits the balance between easy to understand but still accurate.
1 Like
The proposal states that
These "order-dependent operations" are available for use because Set and Dictionary conform to Sequence. Major changes to the protocol hierarchy for Swift standard library collection types are out of the scope of this proposal, if not out of scope for Swift 5 entirely.
As people seem to see this issue less important because Set does support == now, I think we shouldn't change the naming now.
If we really want to resolve the issue, we need a name like allElementsEqualInIterationOrder_dontUseWithSetOrDictionary - or we just take the time to do things properly and fix the protocol hierarchy.
There hasn't been a single argument why Set and Dictionary should support order dependent operations, so we should get rid of the real source of confusion. This would obviously take more time, but I don't see a reason to hurry this topic.
4 Likes
Set and Dictionary should absolutely support iteration, and that means implementing Sequence, which means allowing this function to be called on them.
We’ve had this debate before. Introducing two types of sequences (ordered and unordered) is way more complicated than you think both in implementation and in usage. IMO it’s not even close to worth it.
1 Like
Could you please link to that discussion? That's the first thing I've been asking for...
Maybe it's less complicated than you assume, because the obvious solution breaks with your first statement:
Iteration requires Sequence now - but maybe that's just wrong?
Set and Dictionary are no sequences, so it's quite irritating that they conform to Sequence. On the other hand, something like Iterable shouldn't be that hard to establish.
An unordered sequence is a contradiction (at least for someone with a mathematical background), and I'm not sure if Sequence actually carries it's own weight at all.
There might be some complications with other collection-protocols, but nothing specific has been mentioned so far, so I think it's justified to question the status quo.
2 Likes
Just to say, I've been following this thread and the previous one, and the only name that made me understand instantly and completely was elementsEqualInIterationOrder.
This was the previous discussion: [Draft] Rename Sequence.elementsEqual - #108 by Adam_Kemp1 (starting with my first comment explaining the complications involved). Eventually it ends up with someone suggesting new language features just to make it workable.
I should say I made some mistakes in my explanations, but I don't think those mistakes invalidate the argument. Having two sequence types (one ordered and one unordered) is just not going to be easier to use. It will be much harder to use.
I am -1 on the proposal as a whole (I don't think we should rename the method), and +1 on the proposed name if we do decide to rename it (we already bikeshed this once; let's not do this again). I agree with others who have pointed out that the existence of == now makes this issue less important.
I will also point out that the problem this is trying to solve is not a problem with the name of the original method and not a problem with Set implementing Sequence. The problem is that people don't understand what Sequence is in the first place. If you think Sequence implies a well-defined, deterministic, predicable, or consistent ordering then you are wrong about Sequence. That's not what it is.
Renaming this method to include "in iteration order" won't help people who think Set's implementation of Sequence will yield a predictable order. It doesn't actually solve the problem that is the motivation for the proposal.
Making Set not implement Sequence doesn't solve the problem either because there's nothing about Sequence that can't be fulfilled accurately by Set. It's the understanding of what Sequence is that is the problem. That seems like an education problem to me. Documentation for Sequence and any documentation that introduces its usage should make it absolutely clear that Sequence only describes how to iterate over things and does not guarantee predictability, determinism, or consistency.
I read the thread up to its end, and I have to say I‘m disappointed... I wouldn‘t even call it a real discussion 
I expected some real problems with collections, but I didn‘t find anything like that.
Yes, indeed... both set and sequence have a well established meaning, and the protocol hierachy breaks with it - so it‘s no wonder that people are confused:
It‘s the same confusion that would happen if we‘d call 3.141592 an integer, or associate ”+“ with multiplication.
3 Likes