michal-dobrogost

Thanks for digging that up. It's a shame to accept the status quo here as the current behaviour as is so unexpected, silent and dangerous. I can put up a...

We can't use your example to show that alignment coercian is safe because there is no alignment coercian in your code (but there is in the original example).

FWIW here is the doc comment I have ready for `alignedAlloc` but it doesn't address the underlaying issue just helps prevent some people from blasting their feet off. ``` +///...

Can you coerce and then pass into free safely?

Exactly, `free` depends on the alignment information encoded in the type which combined with alignment coercion rules results in unsafe code. The structure of your counter example can be used...

With the distinction that the unsafe operation for undefined values is accessing them, and for alignment coerced values it is freeing them.

Agreed - some code doesn't interact with allocation at all. I think that sidesteps the issue. A lot of (most?) code does and we should consider it. IMO memory management...

Another take on `nocoerce` would be to have it be part of the type instead of a function annotation. An example of the returned type: `const data: [](align 4) u8...

I built zig with no alignment coercion (one line changed in [Sema.zig](https://github.com/ziglang/zig/blob/181b25ce4fcebc32f6fdc7498148c0f5e131dda9/src/Sema.zig#L30253)). The build flags 68 alignment coercions (compared to 3099 instances of `intCast` in the src folder). This seems...

That's an illuminating perspective. Even if there was ownership tracking, allowing this coercion during ownership transfer would be a mistake, so I'm not sure that ownership is the core issue....