Remove AssocList? about motoko-base

[chenyan-dfinity]

I think other modules are using it, e.g. TrieSet/TrieMap. The name says it's a List not a Map, and hopefully will convey the right time complexity?

[rossberg]

I think it's is safe to assume that 75% of programmers do not know about time complexities, and select data types solely by interface. AssocList is more attractive to use than maps, because you don't have to provide an ordering for the key type, and because it can be shared.

If we can't remove it, then we should at least put a big fat warning in the documentation.

[lsgunnlsgunn]

FWIW, I know some of our example apps import AssocList. If that isn't the best choice, maybe we should revisit/update the examples that use it?
Or possibly incorporate the warning message somehow in the examples?

[matthewhammer]

This issue could be closed, IMO.

Yet their existence may mistake programmers into thinking that their use is adequate when it isn't.

They are "adequate" so long as the lists are bounded, as they are in the Trie, which uses them in its implementation.

I think it's is safe to assume that 75% of programmers do not know about time complexities

Probably not true of the developers that are first to approach the Internet Computer, but I take the general point about hiding things that are not efficient enough to be useful in real systems, at large scales.

But AssocList is useful in real systems, so long as the lists are not "too long." :)

Regarding scaling: There are so many different gotchas we have yet to address, that this one (still) seems like a minor one to me. (A more urgent issue is having any representation for stable memory that is efficient.)