# Add rustc flag to disable mutable no-aliasing optimizations?

**URL:** <https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404>\
**Category:** compiler\
**Created:** [April 2, 2021, 4:21am UTC](https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404 "2021-04-02T04:21:20Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![felix.s](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/felix.s/32/8073_2.png) [@felix.s](https://internals.rust-lang.org/u/felix.s)\
**Post date:** [April 3, 2021, 6:15am UTC](https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404/18 "2021-04-03T06:15:38Z")

</div>

> [@rpjohnst](#):
>
> Consider `UnsafeCell` as an example- as a lang item, it's a fundamental primitive that the compiler has to know about. It could have been provided as special syntax, like C++'s `mutable` . Defining it as a `struct` in a Rust source file is more of a convenience than anything (i.e. it can get away with reusing 99% of the syntax and semantics of a normal struct, it just needs to tweak some compiler analysis), but even then there's not much flexibility in _how_ you define it.

I remember having this discussion before, [about `offset_of`](https://internals.rust-lang.org/t/pre-rfc-add-a-new-offset-of-macro-to-core-mem/9273/25?u=felix.s) (whether it should be a keyword or an intrinsic macro) and [about `await`](https://internals.rust-lang.org/t/on-why-await-shouldnt-be-a-method/10010/56?u=felix.s) (if it should be a keyword or a method with an exotic calling convention). The thing is… it doesn’t matter much. Either way the decision is made, you’re still accessing the same compiler intrinsic that behaves the exact same way and has the exact same limitations and overheads. The only thing that changes is syntax. That’s not to say syntax doesn’t matter at all – sometimes it matters more than in other situations. But let’s not pretend this issue is something more profound than that.

And by the way,

> [@Subsentient](#):
>
> C can be divorced entirely, even from the freestanding headers.

This isn’t true in C either. You cannot write your own `offsetof` macro without invoking UB. You cannot write your own `stdarg.h`. You cannot portably compute `INT_MIN` or define `uint32_t` without `#ifdef`s checking for each particular target and compiler. You cannot write your own `typedef` for the type returned by the `sizeof` operator without `size_t`. And it doesn’t make sense to give up those things any more than it does to give up the `volatile` keyword.

I can agree that accessing fundamental compiler intrinsics ought not to pull in additional runtime cost, but I think the `core` versus `std` split accomplishes that already quite well. I see no good reason to ever forgo `core`: it doesn’t save you any resources, and it doesn’t grant you any extra degrees of freedom over just using the already-implemented version. Even if you defined your own `UnsafeCell`, you’d still have to use it the same way as the one defined in `core`, because the only possible implementation is using the `#[lang]` attribute to say ‘yes, compiler, this is that thing’. It would be at best an exercise in reinventing the wheel.

---

_[View the full topic](https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404)._