extern(C++) and struct (constness mangling problem ?)

[deadalnix]

Le 29/11/2011 22:09, Andrei Alexandrescu a écrit :
> On 11/29/11 11:39 AM, deadalnix wrote:
>> Le 29/11/2011 19:52, Andrei Alexandrescu a écrit :
>>> On 11/29/11 10:50 AM, deadalnix wrote:
>>>> 2/ Use that stract/class as a value type. You can do POD, but also
>>>> define constructor and destructor, copy constructor and overload
>>>> assignement. Anyway, you'll never be able to use proper polymorphism
>>>> here, because it would require virtual destructor at least. This is
>>>> IMO,
>>>> what D's struct should achieve.
>>>
>>> Yes.
>>>
>>>> The 2/ case is overly used in almost any C++ program. And D struct
>>>> should be able to match them. It wouldn't require much to make it
>>>> working :
>>>> - Default constructor.
>>>
>>> No.
>>>
>>
>> No, as "No it will never be done for reason xxx" or as in "No you are
>> wrong and it not necessary, here the way to do : xxx".
>>
>> In both cases, the xxx is the most interesting part :'(
>
> Neither :o). The default initializer that doesn't do any real "work",
> does not throw, and puts the object in a state without ex-situ ownership
> has brought D too many benefits to ignore.
>
> We should be able to define types that refuse default initialization (a
> la non-null pointers), but if the default initializer exists, it's good
> as it is.
>
>
> Andrei
>

I do not question the benefit of initializer that don't do any real 
"work" as you said. This is definitively a good thing.

What I question, is the impossibility for the programmer to do another 
way. This result in very convoluted way to interract with C++. The D 
phylosophy is to enforce a clean and safe way to do thing (and default 
initializer definitively goes in that direction) but also open the 
possibility to get dirty and do whatever is required to do yout hanky 
panky stuffs.

Here is what I suggest :
  - struct with no default constructor just behave the same way as the 
did until now.
  - struct can disable the default constructor as it is possible now. If 
you create a variable of that type without initialization, you get an error.
  - struct can define a default constructor. You get the same errors as 
you get when you disable that default constructor.

With some code :
struct S {
     // default constructor defined or disabled
}

S s; // Error if the default constructor is defined or disabled;
S s = S(); // OK if you have a default constructor, error otherwize.
S s = S.init; // Call the postblit if a default constructor exists or is 
disabled

That way, we keep the benefit of default initializer for most struct, 
but open the door for programmers that don't know what fear is about.

This modify the behaviour of the struct, but, ATM, the default 
constructor can be disabled, and it result in inconsistent behaviour 
(exemple 1 generate error, exemple 3 compile fine and don't call postblit).

As the behaviour is different - we losse benefits of default 
initializers -, we may want to explicit that with a keyword. As you 
suggested, this is similar with non nullable references and could use 
the same keyword (and this is a feature that is missing definitively, 
null check is so easy to forget that it would be great that the compiler 
help us in the task).

This definitively have an impact on severals aspect of D (resising 
arrays is a good exemple). Thoses would be impacted by the default 
constructor caracteritics (eventually can throw, become exepensive in 
computation, etc . . .). We may want to disable thoses operations on 
such types or limit them in some ways.

By the way, bug on opAssign is filled now.