Good question, the use-case I encountered is in implementing some kind of lazy-map and I wanted to implement all the relevant interfaces so that all the functions on regular map would work and be kept in the same "lazy" domain, i.e: (merge lazy-map1 lazy-map2) => lazy-map3

but select-keys for example, explicitly constructs a map {} within it, so there's no way to override this with a protocol implementation.

sounds like you should go the other way

define your own polymorphic select-keys and use c.c/select-keys as the default impl

Yeah that's what I did

Thanks 🙏:skin-tone-3:

But my question was honest, I saw the implementation and thought that it could go in some map protocol. I think it still can be patched with no breaking changes, that's why I asked if there was a specific reason it wasn't done, is there some intentional design decision behind it? And if there isn't, can I submit a patch for it?

Seems like empty could be used for it to be polymorphic too. But haven't looked much.

usually core protocols denote primitive functionality, select-keys is not such. I can see an argument why merge may be

@U060FKQPN I agree, if select-keys can be implemented on top of more primitive protocols that given an implementation would keep the structure in the source type that's the way it should be. Another aspect to consider: clojure/script never made the commitment that data structures would keep their original type after transformations, iiuc, mostly due to laziness.

Does anyone know where can I ask about this suggestion \ contribution?

@U050B88UR maybe you can help me here? how can I promote reimplementing map functions (currently I observed only select-keys & merge) based only on protocol functions? Or, if I can't, (perhaps because there's a reason for them to be implemented that way) you can shed more light and I can become a better clojurian 😅