Oh, slightly more info as to why this matters.

The ShortcutManager performs a hash lookup of the currently pressed keys to determine whether there's a matching intent. With the possibility of a hash mismatch, the intent may not found.

Oh, my. OK, we'll have to do something to fix that (probably sort them when inserting, or just use a different data structure).

By default the Set and Map types or via literals in dart preserve insertion order. To get an unordered set you'd have to explicitly use HashSet or HashMap

Well, but would iteration order matter in a hash set? Or, even better, does hashCode on a HashSet provide a hash of the contents?

Iteration order is the preserved insertion order for LinkedHashSet and LinkedHashMap (the defaults). Map/Sets in general are mutable and don't have a meaningful hashCode.

One thought is to use a TreeSet sorted on keyId. That would make iteration order consistent regardless of insertion order, and therefore a consistent value produced by hashList

Edit: The class is called SplayTreeSet in dart:collection

Do the key sets always contain 4 keys?

No, at most 4 in the default constructor, but there's a fromSet constructor for arbitrary length.

I have a PR that fixes this. HashSet is sufficient, since the iteration order seems to depend on the hash value of the elements.

From the docs for HashSet:

"The iteration order of the set is not specified and depends on the hashcodes of the provided elements. However, the order is stable: multiple iterations over the same set produce the same order, as long as the set is not modified."

This is perfect for this use case.

What would happen if two hash codes collide? It may depend on the implementation of the map. I'm going to throw together a dartpad and see if I can break it.

FWIW SplayTreeSet is as slow as molasses

OK, it's a contrived example, but demonstrative. Using a HashSet, I forced a hash collision by having two elements return the same hashCode, but register as unique in their operator ==. In this case, iteration order reflects insertion order.

It's difficult to say how this might happen in a real-world scenario, but it may very well be possible. Whether or not there's a collision of this kind is presumably based on the number of buckets the HashSet uses.

FWIW SplayTreeSet is as slow as molasses

Just a suggestion. Might be useful just to get things into sorted order, and generating the hashCode up front. You can ditch it after that, since the set is immutable and the only check you need afterwards is set equality.

Scratch that. After trying pretty hard to get a collision in a real-world situation, I couldn't do it. It's probably not a big deal.

Yeah, that definitely won't happen with LogicalKeyboardKeys. They use their unique keyId for both the operator== and the hashCode.

And if something does return false from operator= and produce the same hashCode, it is violating the contract for the hashCode property, which states "Hash codes must be the same for objects that are equal to each other according to operator ==. "

If you read that carefully, you'll see it doesn't really say that.

If they are equal, they must return the same hashCode, but it doesn't say anything about the behavior when they're unequal. That's why hash sets and maps rely on both hashCode and equality to determine membership.

Thanks for the PR though. Appreciate it.

My apologies, you're correct.

In this case, LogicalKeyboardKey is always going to return a different hash code if the two keys have different keyIds, so it isn't a concern.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.