Go, D, and the GC

[Timon Gehr via Digitalmars-d]

On 10/08/2015 05:20 AM, Shachar Shemesh wrote:
> On 07/10/15 12:58, Timon Gehr wrote:
>
>>> Shachar
>>
>> struct S{
>>      @disable this();
>>      @disable enum init=0;
>> }
>>
>> void main(){
>>      S s; // error
>>      auto d=S.init; // error
>> }
>>
>
> An honest question. Would that also cover all cases where init is being
> used implicitly by the compiler?
> ...

Construction does not currently work without init, but there it is no 
problem. Anyway, the right question is whether there is any way that the 
invariant of a type can be broken by bypassing the constructor using 
only @safe features. That's actually what @disable this() should 
prevent, apparently modulo explicit usages of init (which does not make 
that much sense).

> I will need to do some research myself, but my gut feeling is "no".
> There are several cases where the compiler replaces the value with the
> init value, and I doubt your horrid hack changes that.
> ...

I would consider any way that init sneaks in unexpectedly to be a 
compiler bug related to @disable this().

> Either way, I think you'll agree that D needs to be better in defining
> what is the correct path to take on this, as, currently, nobody seems to
> know for sure.
>

Obviously. Overriding of init should be removed and the use case should 
be supported in a different way. (This could probably just be, e.g., 
make @disable this() also disable init.) I just showed what we've got, 
and, for better or worse, it's actually in the language by design.