# Deprecate static mut (in the next edition?)

**URL:** <https://internals.rust-lang.org/t/deprecate-static-mut-in-the-next-edition/19975>\
**Category:** language design\
**Created:** [December 4, 2023, 2:31pm UTC](https://internals.rust-lang.org/t/deprecate-static-mut-in-the-next-edition/19975 "2023-12-04T14:31:23Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [December 7, 2023, 8:20pm UTC](https://internals.rust-lang.org/t/deprecate-static-mut-in-the-next-edition/19975/12 "2023-12-07T20:20:01Z")

</div>

> [@pitaj](#):
>
> and `warn` for any usage?

I'm generally opposed to any sort of "whenever you use this language feature _at all_ you get a warning" plan.

This regularly comes up related to floats, for example, around things like warning about `x == 0.0`. And yes, there's gotchas about that, but it's also possibly the right thing. So I really don't want a lint that basically becomes `#![allow(yes_i_know_that_i_am_using_floats)]`.

I think "there's a better way that you should write this instead" warnings are usually a better fit for more opinionated tools -- rustc usually oughtn't bother you if you're doing something _fine_, even if it's something _not great_, at least for things that are internal to your crate. That helps encourage people to take seriously the warnings they _do_ get.

Though certainly the line between "not great" and "error-prone" is often fuzzy.

> [@kornel](#):
>
> So jumping immediately to deny would be skipping a step.

Jumping to _deny_ inside an edition is allowed, just not to _error_. Though it's certainly rare, because things we feel strongly enough to `deny` in rustc are uncommon.

---

_[View the full topic](https://internals.rust-lang.org/t/deprecate-static-mut-in-the-next-edition/19975)._