Go, D, and the GC

[Marc Schütz via Digitalmars-d]

On Monday, 5 October 2015 at 10:57:57 UTC, Shachar Shemesh wrote:
> On 05/10/15 13:39, Marc Schütz wrote:
>> On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh 
>> wrote:
>>> What's more, init is used even if you @disable this(). The 
>>> following
>>> compile and does what you'd expect (but not what you want):
>>> struct S {
>>>    int d;
>>>
>>>    @disable this();
>>>    this( int d ) {
>>>       this.d = d;
>>>    }
>>> }
>>>
>>>
>>> ...
>>>
>>>    S d = S.init;
>>
>> I don't understand this. How is that not what you want, 
>> considering that
>> you explicitly told it to use the init value?
>
> One of the basics of C++ is that, if you construct the type 
> correctly, then the user of the type cannot use it in a way 
> that will cause inconsistencies. Such a use will not compile.
>
> The above shows that you cannot construct such a type in D. The 
> language simply does not allow you to cancel a certain feature 
> of the type in which you are uninterested.

`@disable this();` works fine to prevent the user from doing that 
accidentally. But in your example, this doesn't happen by 
accident; you explicitly told the compiler to use the .init 
value. That's not something you do just because you can, you need 
to have a reason for it. Presumably a user doing this would know 
what they're doing.

I don't think it's reasonable to expect to be able to prevent 
that, just as you can't forbid the user to do unsafe casts. And 
arguably, if your type's .init is invalid, then "you're doing it 
wrong".

Besides, that every type has a .init value is a very fundamental 
part of the language, not just a feature of a particular type. 
Sure, you use some flexibility for edge cases, but IMO that's a 
good tradeoff for the general advantages you gain from it.

>
> Please bear in mind that the init might not be called directly. 
> Programmer A defines a type that should never be uninitialized 
> (i.e. - needs a constructor). Programmer B places an instance 
> of that type inside a containing struct. Programmer C uses that 
> containing struct's init. Such a problem is not easy to catch, 
> even if programmers A, B and C are the same person.
>

If you use normal declaration, the compiler correctly rejects 
that:

struct A { @disable this(); }
struct B { A a; }
void main() { B b; }

// Error: variable xx.main.b default construction is disabled for 
type B

If you'd use B.init, of course you'd get exactly what you ask 
for, see above.