On Wednesday, 29 December 2021 at 01:11:13 UTC, Stanislav Blinov wrote:

Stuff[Key] aa;
aa[key] = Stuff(args); // ostensibly, initialization
aa[key] = otherStuff;  // assignment to existing value

Of course but opIndexAssign() isn't there in my example. The compiler should call runtime's _aaGetY() or something like that directly.

On Wednesday, 29 December 2021 at 02:33:08 UTC, frame wrote:

Stuff[Key] aa;
aa[key] = Stuff(args); // ostensibly, initialization
aa[key] = otherStuff;  // assignment to existing value

It is doing that. You've asked why that should be compile error, and the answer is - because there's no way to distinguish between initialization and assignment here. I.e. you can't make one line compile and the other - not. Either both compile, or both don't. So if you allow them to compile, you'll have to have a runtime check, throwing an exception on attempt to assign. Which is just horrible. Better to leave the assignment a compile error, and make require and update do the job they're supposed to be doing.

On Wednesday, 29 December 2021 at 01:11:13 UTC, Stanislav Blinov wrote:

Stuff[Key] aa;
aa[key] = Stuff(args); // ostensibly, initialization
aa[key] = otherStuff;  // assignment to existing value

So i wonder if const and immutable would have different behaviors then.

While you shouldn't be able to explicitly change a const item within a struct, replacing the whole struct i would think would be okay, on the basis that you're basically throwing whole old item away (and may be equal to what you'd do with say swap).

Immutable on the other hand may want to refuse as it should basically have a lifetime of the array? Though if you can delete the item and then just add it in again it's a longer version of the same thing, just depends on if anything is using/referencing it or not. And casting away the constness is easy enough so maybe it won't be different.

Though if it's a basic type it seems unlikely it would need a longer lifetime, and if it's a reference or array it already is separated from the struct and needs no such protection for the pointer.

I don't know. I remember odd behavior with const/non-const stuff before.