Interesting, I would never expect Map.to_list/1 like functions guarantee
results in specific order especially if these maps are equal %{a: 1, b: 2},
%{b: 2, a: 1}.
In example you've given, we have numbers as string keys and the items order
after conversion to a list you expect is unclear given that strings sorted
differently than numbers ("9" > "100" => true).
> On 30 Oct 2022, at 00:27, Zach Daniel <zachary.s.dan...@gmail.com> wrote:
>
> The way that this can lead to bugs is when you dynamically build a map, and
> then later iterate over the keys and values in some way that depends on the
> order (which is the actual bug here) but you don't notice because the map has
> a stable sort. In this instance, we had code in AshPhoenix that was working
> with the params that come back from a Phoenix.HTML.FormData form, that looks
> like this:
>
> %{"0" ⇒ …, "1" ⇒ …., "2" ⇒ ….}
>
> And we then turn that into a structure like `[%{...}, %{...}, %{...}]` and we
> were not properly sorting. The test suite didn't ever use 10 or more
> elements, but when a user did, they saw their forms no longer coming back in
> the order they were in the HTML, but form 10 was after form 1, because the
> map was string key sorted. This is just one example, I've been bitten by this
> a few times. The actual problem is of course iterating over a map when the
> order matters, but the point is that by having a predictable, stable behavior
> below 32 elements, it increases the likelihood that a programmer wouldn't
> notice that they had done that.
>
> With that said, based on the value being baked into the VM as a C constant,
> its definitely not worth the effort to find some way to alleviate this issue
>
>
> On Sat, Oct 29, 2022 at 4:19 PM, Boris Kuznetsov <m...@achempion.com
> <mailto:m...@achempion.com>> wrote:
> Could someone please share an example when it can lead to bugs in a system
>
> To me maps are simple key/value data structure which gets accessed through
> direct work with a key or pattern matched against
>
>> On 28 Oct 2022, at 06:20, Zach Daniel <zachary.s.dan...@gmail.com
>> <mailto:zachary.s.dan...@gmail.com>> wrote:
>>
>> Myself and many other developers have been bitten by the fact that maps are
>> sorted if they have less than 33 elements. Not because we believed that we
>> should rely on the sort ordering of a map, but because we *accidentally*
>> wrote an implementation that did, and didn't test it with more than 32
>> elements. Then at some point later in actual use things get strange, and
>> debugging the above scenario can be very difficult (but is of course obvious
>> in retrospect). This could be opt-in or opt-out, all the same to me,
>> although unless the performance impacts are huge I think that it would save
>> new developers even more time than experienced developers and so should
>> potentially be opt-out. After a while when you start to see things "showing
>> up in weird orders" you have an intuition to go look for a map being
>> enumerated, but that isn't something a beginner would likely think of.
>>
>> As far as I know this is an erlang thing, but I'm not too familiar with
>> erlang and thought I'd float it by the elixir group first. I'm also not sure
>> if its possible to change those constants based on Mix environments (or to
>> change them at all), but I imagine that is where it will intersect with
>> Elixir.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com
>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/a528c1bb-b8e1-429c-b1ff-a98db36ee2d6n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/a528c1bb-b8e1-429c-b1ff-a98db36ee2d6n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/8C768E7E-61D7-4B69-956D-16567D2998DC%40achempion.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/8C768E7E-61D7-4B69-956D-16567D2998DC%40achempion.com?utm_medium=email&utm_source=footer>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/l9uhk9qo.38af49dc-4df8-4c53-8ff7-493fad67302b%40we.are.superhuman.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/l9uhk9qo.38af49dc-4df8-4c53-8ff7-493fad67302b%40we.are.superhuman.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/1021D9B7-68B5-469E-AAE4-71753FF85ADD%40achempion.com.
