# CLC Proposal #341: Strict variants of mutable data types

**URL:** <https://discourse.haskell.org/t/clc-proposal-341-strict-variants-of-mutable-data-types/12403>\
**Category:** Core Libraries Committee\
**Created:** [July 2, 2025, 12:48pm UTC](https://discourse.haskell.org/t/clc-proposal-341-strict-variants-of-mutable-data-types/12403 "2025-07-02T12:48:27Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![rumaan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/rumaan/32/5158_2.png) [@rumaan](https://discourse.haskell.org/u/rumaan)\
**Post date:** [July 2, 2025, 12:48pm UTC](https://discourse.haskell.org/t/clc-proposal-341-strict-variants-of-mutable-data-types/12403/1 "2025-07-02T12:48:27Z")

</div>

At Scrive, we have found on several occasions – due to the efforts of [@arybczak](https://github.com/arybczak) – space leaks coming from the default, lazy-evaluated implementation of the `MVar` API.  
This has been the initial motivator to create the [`mutable-strict-base`](https://flora.pm/packages/@hackage/strict-mutable-base) library. (See the original announcement: [here](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266)).

However, the fact remains that pernicious lazy evaluation in mutable types from the `base` library is a source of confusion, with real consequences for users down the line.

I have opened a proposal, written from the perspective of someone who has to diagnose thunk retention in production, which usually implies scouring one’s codebase and its dependencies.

You can view the proposal at [Strict variants of mutable data types · Issue #341 · haskell/core-libraries-committee · GitHub](https://github.com/haskell/core-libraries-committee/issues/341)

---

_[View the full topic](https://discourse.haskell.org/t/clc-proposal-341-strict-variants-of-mutable-data-types/12403)._