On Fri, 28 May 2010 20:26:50 -0500, Andrei Alexandrescu wrote:

> Walter has had a great idea last night: allow classes to define
> 
> this(ref S src);
> 
> where S is the name of the struct being defined, as an alternative for
> 
> this(this);
> 
> The result would be a function similar with a C++ copy constructor.
> 
> Such an abstraction allows us to perform lazy initialization in a way that allows the kind of problems associated with non-shared hash tables:
> 
> void foo(int[int] x)
> {
>     x[5] = 5;
> }
> 
> void main()
> {
>     int[int] x;
>     foo(x);
>     assert(x[5] == 5); // fails
> }
> 
> If you change the first line of main() with
> 
> int[int] x = [ 42:42 ];
> 
> the assert passes.
> 
> The idea of the copy constructor is to lazy initialize the source and the target if the source has null state. That would take care of this problem and the similar problems for shared state.
> 
> There is still a possibility to call a method against an object with null state. I think that's acceptable, particularly because lazy initialization saves some state allocation.
> 
> What do you think?
> 
> 
> Andrei

Nothing wrong with yet another widely available constructor tool if the user optionally wants to have it available and use it that way, and its usage is well defined.

Good if no cost if the programmer does not use the facility.

What seems to be missing, in this example of the unintentional creation of 2 AAs because initially a null AA is passed, if there was a way of explicitly initialising the AA first without having to insert something into it.   That subject seems to be taboo.  Of course, an empty but setup AA can be kludged by adding an arbitrary value and then removing it, and as such begs the need for a setup property / function.

\\

On Fri, 28 May 2010 20:26:50 -0500, Andrei Alexandrescu wrote:

> Walter has had a great idea last night: allow classes to define
> 
> this(ref S src);
> 
> where S is the name of the struct being defined, as an alternative for
> 
> this(this);
> 
> The result would be a function similar with a C++ copy constructor.
> 
> S.
> 
> What do you think?
> 
> 
> Andrei


Thats great.
Yet another way to initialize an AA, without having to insert and then
remove a value.  I just have to make a dummy function and pass the AA to
it.

Maybe a setup property / function would be easier.

On 29/05/2010 03:02, Jonathan M Davis wrote:
> Andrei Alexandrescu wrote:
>
> Not knowing what other implications there are, I'm fine with the change, but
> the fact that D creates the array when you try and insert into it (or append
> to it in the case of normal arrays IIRC) rather than blowing up on null
> seems like a source of subtle bugs and that perhaps it's not the best design
> choice. But maybe there was a good reason for that that I'm not aware of, so
> it could be that it really should stay as-is. It's just that it seems
> danger-prone and that the situation that you're trying to fix wouldn't be an
> issue if the array stayed null until the programmer made it otherwise.
>
> - Jonathan M Davis

Yeah, I agree. I mean, for me the problem here is that the map/associative-array is not really a value type, nor a reference type, but something in between. I think it might be better for it to be just a proper reference type.

I'm not saying that Andrei suggestion has no merit though. Rather, I have to admit I am not familiar with these C++ idioms and techniques. Can someone explain me why we need a copy constructor in the first place, instead of just using a reference object, aka a class, and an optional clone method?



-- 
Bruno Medeiros - Software Engineer

On 06/03/2010 06:30 AM, Bruno Medeiros wrote:
> On 29/05/2010 03:02, Jonathan M Davis wrote:
>> Andrei Alexandrescu wrote:
>>
>> Not knowing what other implications there are, I'm fine with the
>> change, but
>> the fact that D creates the array when you try and insert into it (or
>> append
>> to it in the case of normal arrays IIRC) rather than blowing up on null
>> seems like a source of subtle bugs and that perhaps it's not the best
>> design
>> choice. But maybe there was a good reason for that that I'm not aware
>> of, so
>> it could be that it really should stay as-is. It's just that it seems
>> danger-prone and that the situation that you're trying to fix wouldn't
>> be an
>> issue if the array stayed null until the programmer made it otherwise.
>>
>> - Jonathan M Davis
>
> Yeah, I agree. I mean, for me the problem here is that the
> map/associative-array is not really a value type, nor a reference type,
> but something in between. I think it might be better for it to be just a
> proper reference type.

An associative array is a reference type. The problem discussed above applies to all reference types.

> I'm not saying that Andrei suggestion has no merit though. Rather, I
> have to admit I am not familiar with these C++ idioms and techniques.
> Can someone explain me why we need a copy constructor in the first
> place, instead of just using a reference object, aka a class, and an
> optional clone method?

The problem is that null objects don't obey reference semantics. The example discussed in this group is:

void fun(int[int] a) { a[5] = 10; }

void main(string[] args) {
    int[int] x;
    if (args.length & 1) x[0] = 42;
    fun(x);
    assert(x[5] == 10);
}

The program will fail or not depending on the number of arguments passed.


Andrei

On 03/06/2010 14:48, Andrei Alexandrescu wrote:
> On 06/03/2010 06:30 AM, Bruno Medeiros wrote:
>> On 29/05/2010 03:02, Jonathan M Davis wrote:
>>> Andrei Alexandrescu wrote:
>>>
>>> Not knowing what other implications there are, I'm fine with the
>>> change, but
>>> the fact that D creates the array when you try and insert into it (or
>>> append
>>> to it in the case of normal arrays IIRC) rather than blowing up on null
>>> seems like a source of subtle bugs and that perhaps it's not the best
>>> design
>>> choice. But maybe there was a good reason for that that I'm not aware
>>> of, so
>>> it could be that it really should stay as-is. It's just that it seems
>>> danger-prone and that the situation that you're trying to fix wouldn't
>>> be an
>>> issue if the array stayed null until the programmer made it otherwise.
>>>
>>> - Jonathan M Davis
>>
>> Yeah, I agree. I mean, for me the problem here is that the
>> map/associative-array is not really a value type, nor a reference type,
>> but something in between. I think it might be better for it to be just a
>> proper reference type.
>
> An associative array is a reference type. The problem discussed above
> applies to all reference types.
>
>> I'm not saying that Andrei suggestion has no merit though. Rather, I
>> have to admit I am not familiar with these C++ idioms and techniques.
>> Can someone explain me why we need a copy constructor in the first
>> place, instead of just using a reference object, aka a class, and an
>> optional clone method?
>
> The problem is that null objects don't obey reference semantics. The
> example discussed in this group is:
>
> void fun(int[int] a) { a[5] = 10; }
>
> void main(string[] args) {
> int[int] x;
> if (args.length & 1) x[0] = 42;
> fun(x);
> assert(x[5] == 10);
> }
>
> The program will fail or not depending on the number of arguments passed.
>
>
> Andrei

In my notion of reference type (which you may argue is not the correct one, but that's a different issue) a null object cannot be used at all (other than checking its identity against other objects). Thus that program would always fail, either on 'a[5] = 10;' or 'x[0] = 42;', according to these semantics


-- 
Bruno Medeiros - Software Engineer