Struct no-arg constructor?

[deadalnix]

Le 25/07/2012 11:51, Jonathan M Davis a écrit :
> On Wednesday, July 25, 2012 11:34:12 monarch_dodra wrote:
>> According to TDPL, the rationale for structs not having default
>> constructors is "T.init", were T.init is defined as:
>> *A static, known at compile time, mem-copyable value.
>> *The value that gets mem-copied into structs before the
>> constructors are called
>> *The value that gets mem-copied into structs when moving stuff
>> out of them.
>> **Destructors must support being called on a T.init element.
>>
>> The thing is, I can't, for the life of me, understand how that
>> interferes with having a default constructor. Wouldn't keeping
>> the current definition of init, but allowing a call to a "no-arg"
>> constructor after after the mem-copy of T.init also work? As long
>> as the destructor keeps supporting calls to T.init objects, then
>> all is fine. Why hold out on a very useful functionality?
>>
>> Am I missing a case where having a default constructor could
>> actually mess things up? The restriction just feels gratuitous
>> for me.
>
> If you want to be able to do S(), then declare a static opCall for S which
> returns an S constructed in the way that you want.
>
> struct S
> {
>      static S opCall()
>      {
>          //do whatever you do
>          return s;
>      }
> }
>
> auto s = S();
>
> but
>
> S s;
>
> will always be init. But you can't have a default constructor, because then it
> conflicts with what init would be doing. e.g. would
>
> S s;
>
> be initialized with init or with the default constructor? But the static
> opCall does let you construct a struct without any arguments. You just can't
> have anything which isn't explicitly constructed using a default constructor,
> because that's init's job.
>
> Also, because all types must have an init value, if you can't guarantee that
> your struct is valid and usable with its init property, then you'll either
> have to disable the struct's init value so that it cannot be use
>
> struct S
> {
>      @disable this();
> }
>
> or you'll have to live with the fact that using it could blow up in your face
> - which really isn't all that different from other types (e.g. float.init is NAN
> and pointers default to null).
>
> - Jonathan M Davis

Static opCall isn't a solution. You can't new on it. And it seems weird 
that you can disable something that don't possibly exists in the first 
place.

This topic comes back again and again on the NG, it have to be considered.

If I get a concrete example, let say RefCounted, I can see in the source 
code that many checks are performed to handle the case where the struct 
is .init . It have a runtime cost and make the code more complex.

It is more error prone because specific cases must be handled all over 
the place. Having .init is certainly an interesting capability of D, but 
in this specific case, it isn't sure it worth it.