https://issues.dlang.org/show_bug.cgi?id=24867
--- Comment #7 from Luís Ferreira <[email protected]> --- > No example you gave here justifies the outer `align(1)` It does. Considering our tracing system: ``` align(1) struct TracesMetadata { align(1): const char* name; int b = 2; } @section(".traces.metadata") @assumeUsed static immutable Bar bar1 = Bar("foo1"); @section(".traces.metadata") @assumeUsed static immutable Bar bar2 = Bar("foo2"); ``` We need both alignment specifiers in order for the section to be fully packed across two of those constants. These items inside the traces metadata section shouldn't have any alignment, or, very specific alignment. The metadata is very much like DWARF `.debug_info`, not supposed to be used at runtime, so everything packed is desired to save space in the binary. Sure you can specify the alignment when you define the constant, but this is here to prevent forgetting and then having issues. These types are never ever used at the runtime of the program. I can't give examples of filesystem, because I don't known enough about it to claim a point. Outer alignment, sure, it makes less sense, but it serves a purpose. The packed outer alignment also makes sense in the context of embedded systems firmware where specific data types that are also often used inside sections are very space constraint (and not performance critical). If you tell me a safety issue using these at the compile-time, sure, but forbidding it to be used within a safe context when its actually 100% safe, for me, it has no sense. Btw, pedantic-wise, we shouldn't also specifically well-define this whole error at all, because this is only unsafe because of limitations or otherwise impractical behaviour of the druntime GC. I don't know how we phrase this in spec, but we should tell its implementation defined. If we take a look at DMD implementation, there's no reason to not allow it, because all the situations I showed above are 100% safe. --
