Why allow initializers of non-static members that allocate?

Bastiaan Veelo Bastiaan at Veelo.net
Fri Jun 10 08:00:44 UTC 2022


On Friday, 10 June 2022 at 07:46:36 UTC, Mike Parker wrote:
> On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote:
>
>> Is there a use case where this makes sense? I would have much 
>> appreciated the compiler slapping me on the fingers, but it 
>> doesn't. I understand that it is safe and that the compiler 
>> can allow this, but why would anyone want that? D-scanner does 
>> not check for this either.
>
> Any initialization of a member field is overriding the field's 
> `.init` value for the type. If a dynamic allocation set a 
> different value per instance, then you'd have inconsistent 
> behavior with, e.g., `int a = 5`.

Yes, I understand that the compiler can't do what I was expecting 
it to do, it was a mistake.

>> I think a helpful error message would be: "Error: The 
>> initializer `A(5)` allocates memory that is shared among all 
>> instances of `S`. If you want that, make `S.a` `static`."
>
> I understand that it's not something that people expect, but 
> making it an error can't be the answer. And making it a static 
> field is not the same thing.

It's not the same thing, therefore I was hoping to see a use case 
for it -- but just because I'm curious; Preventing the mistake is 
my main thing.

> I think this is a case where having a warning that's on by 
> default, and which can be explicitly disabled, is useful. "Blah 
> blah .init blah blah. See link-to-something-in-docs. Is this 
> what you intended?"

That would be fine too. By the way, if there is 
something-in-docs, I don't think it is prominent enough...


-- Bastiaan.


More information about the Digitalmars-d-learn mailing list