Strict maps as newtypes

[meooow25]

Currently we have Lazy and Strict modules for Map and IntMap that act on the same type, which is a potential source of confusion and bugs.

An arguably better situation would be to have strict maps as newtypes over lazy maps. This will prevent maps from being used with the wrong module and allow strict maps to have their own instances. At the same time, it will remain possible to explicitly convert between the types in constant time.

However,

• Do users want to use separate strict types? The strict-containers library exists today, but isn't widely used(?)
• To avoid breakage, it would be best to have this newtype in a separate module. Having two strict modules would be confusing, how do we address that?
• If we were to consider a breaking change and change the Strict module to work on a newtype, what amount of breakage would we see?

[TeofilC]

If we were to consider a breaking change and change the Strict module to work on a newtype, what amount of breakage would we see?

At some point I will look into this. My guess is that we would see little to no breakage, but we need to put that to the test.

[meooow25]

That would be of great help, but how would you go about it?

---

A point that should be mentioned for this issue, which I became aware of later (due to https://github.com/haskell/core-libraries-committee/issues/341#issuecomment-3001283150), is that this really hurts interoperability.

All is well if one is using strict maps for stronger guarantees in one's own code, but for a library that has to accept or return maps this design would introduce a new decision, potentially either duplicating the API or make using it more awkward with conversions at the boundary.

[L0neGamer]

I would like to echo the desire for newtypes (or even entirely separate strict types) to guarantee strictness when it is desired. It is incredibly surprising that despite using Data.Map.Strict throughout your program, you can get leaks because <> can be used on maps that were constructed strictly and maps that were constructed lazily.

To go about this, I'd put warnings on the existing strict module, and create a new module, Data.Map.StrictMap.