Maybe it can be done as a rewrite?
[…]
But this is not quite the semantic we actually want because, for instance, the accessors will still run the invariants, which is pointless because we know the fields won't ever change after the constructor call, and also the function call itself is just useless. But that's the interface we want, at least.

On Wednesday, 1 February 2023 at 07:46:24 UTC, FeepingCreature wrote:

Hm, anyway, if you can do it as a rewrite then you should be able to implement it in the parser and in the runtime. That way you can maintain it even if it isn't added to the core D language.

(If you are interested in something like this, just send me an email.)

I mean, since it's a reduction in capability, it would even be enough to do it as an audit step. Error on any assignment to a field in the struct marked with a UDA.

That can't be done before semantic assignment though...

D libraries like to behave like they can declare variables and assign values to them. (Oh, to live in such innocence!) This is all over Phobos, Dub, etc. immutable struct frustrates this belief. Because you could always take the address of a field, which would be immutable T*, you could see the value changing when you overwrite the variable - a constness violation. immutable solves this by preventing you from modifying the memory of the field while the pointer lives. This largely doesn't work, because people don't test with immutable struct in the first place. If an rvalue struct is used, the naive code works as before, but the type gets the correctness benefits of immutable: you can only construct a new value through the constructor.