# Pre-RFC: #\[align\] attribute
**URL:** https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004
**Category:** language design
**Created:** [June 10, 2024, 7:12pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004 "2024-06-10T19:12:11Z")
**Posts on this page:** 10
**Page:** 2
### Author:  [@scottmcm](https://internals.rust-lang.org/u/scottmcm)
#### Post date: [June 11, 2024, 8:46pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/21 "2024-06-11T20:46:16Z")
> [@2e71828](#):
>
> because here we’re talking about the alignment of _fields_ in-situ
Ok, when it was phrased as "types" in the original post I thought it was still _types_ in the rust sense.
Agreed that if it's just about the alignment of fields it's fine.
---
### Author:  [@binarycat](https://internals.rust-lang.org/u/binarycat)
#### Post date: [June 12, 2024, 3:08am UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/22 "2024-06-12T03:08:17Z")
as i see it, the main utility of this sort of namespacing is preventing namespace pollution... which seems like it has dubious utility, i'm not sure what else `#[align]` could mean in this position exempt exactly this. i guess it's possible there's a proc macro out there that uses this already.
---
### Author:  [@2e71828](https://internals.rust-lang.org/u/2e71828)
#### Post date: [June 12, 2024, 10:09am UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/23 "2024-06-12T10:09:42Z")
> [@scottmcm](#):
>
> Ok, when it was phrased as "types" in the original post I thought it was still _types_ in the rust sense.
Well, it sort of is, because the ideal solution would be to have the ability to define a `WgslVec3` type that will just do the right thing when used in a `#[repr(C)]` structure. But, as you pointed out, that would require breaking a fundamental Rust design choice.
Explicit field alignments like this are the next-best thing, but are still fundamentally a work-around for the impedance mismatch between the two languages.
---
### Author:  [@binarycat](https://internals.rust-lang.org/u/binarycat)
#### Post date: [June 30, 2024, 2:32pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/24 "2024-06-30T14:32:43Z")
another usecase for this would be to guarantee a struct's layout is the same for all architectures. could be useful if it doesn't have any non-u8 fields.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [September 28, 2024, 2:32pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/25 "2024-09-28T14:32:49Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
---
### Author:  [@steffahn](https://internals.rust-lang.org/u/steffahn)
#### Post date: [April 10, 2025, 10:49am UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/26 "2025-04-10T10:49:41Z")
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [April 10, 2025, 2:10pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/27 "2025-04-10T14:10:26Z")
I just learned about [Tracking Issue for `#[repr(align(...))]` on function items (fn\_align) · Issue #82232 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/82232). Perhaps that should use `#[align]` also?
---
### Author:  [@folkertdev](https://internals.rust-lang.org/u/folkertdev)
#### Post date: [April 30, 2025, 5:43pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/28 "2025-04-30T17:43:37Z")
As an extra bit of background/prior art: especially in an embedded context, sections are used to force the alignment of functions and statics.
For embedded projects, you typically define your own sections, and their alignment, explicitly in a linker file. Important functions/statics can get their own section, and the alignment of the item will be the alignment of the section. The section is specified with with [`#[link_section]`](https://doc.rust-lang.org/reference/abi.html#the-link_section-attribute).
Note: this is not a good solution, but one that works today. It's easy to make mistakes with section names or sizes: the `#[link_section]` attribute is unsafe for good reasons. So having `#[align]` directly on statics and functions would be a big improvement.
---
### Author:  [@folkertdev](https://internals.rust-lang.org/u/folkertdev)
#### Post date: [May 1, 2025, 6:15pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/29 "2025-05-01T18:15:39Z")
I asked some embedded folks, to try and find a concrete example, and there is one [here](https://github.com/stm32-rs/stm32h7xx-hal/blob/master/examples/ethernet-nucleo-h743zi2.rs#L54-L56):
```rust
/// Ethernet descriptor rings are a global singleton
#[link_section = ".sram3.eth"]
static mut DES_RING: MaybeUninit> =
MaybeUninit::uninit();
```
Which uses the `.sram3` linker section defined [here](https://github.com/stm32-rs/stm32h7xx-hal/blob/bcb9248c003f3670e5a8c9e19cb54b823bec10ff/memory.x#L55-L58):
```rust
.sram3 (NOLOAD) : ALIGN(4) {
*(.sram3 .sram3.*);
. = ALIGN(4);
} > SRAM3
```
This section performs double-duty: it puts the static in a special bit of ram, but also forces the alignment. With `#[align]`, that alignment can be dropped from the linker file.
* * *
We should not get bogged down with syntax, but T-lang seemed to like `#[align = N]` instead of `#[align(N)]`, So that's something to maybe touch on in an eventual RFC.
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [May 2, 2025, 7:45pm UTC](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/30 "2025-05-02T19:45:52Z")
RFC is up: [RFC: Add an attribute for raising the alignment of various items by Jules-Bertholet · Pull Request #3806 · rust-lang/rfcs · GitHub](https://github.com/rust-lang/rfcs/pull/3806)
[Previous page](https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004.md?page=1)