Please fix `.init` property

[FeepingCreature]

On Friday, 12 January 2024 at 09:57:25 UTC, Iain Buclaw wrote:
> On Tuesday, 9 January 2024 at 06:16:42 UTC, FeepingCreature 
> wrote:
>>
>> Yes, the point of making it forced `immutable` is exactly to 
>> make the problematic cases illegal. Don't even think about 
>> deepcopy vs array vs object etc., just let the const system 
>> handle it.
>
> I might be misinterpreting, but it seems like you're suggesting
> ```
> S s;
> s.arr[0] = "imm"; // compile-time error?
> s.arr = ["new"];
> s.arr[0] = "mut"; // ok
> ```
> I'm not seeing how that would fly.
>
> I can imagine it being easier done at runtime - with a bit of 
> extra overhead - using mprotect or tagged pointers.

Not quite: you couldn't even *define* `S` as

```
struct S
{
     int[] arr = [1, 2, 3]; // Error: immutable(int)[] cannot be 
converted to int[].
}
```

The type of an array-literal, *evaluated at compile-time,* would 
always be immutable. That way, you'd either *have* to define a 
constructor or you would be protected from accidental aliasing 
anyways. You'd be missing out on *intentional* aliasing, but 
that's such a corner case I'm fine sacrificing it.