Old problem with performance

[Rainer Deyke]

Christopher Wright wrote:
> Rainer Deyke wrote:
>>> What mechanism for sharing state is available to by-reference objects
>>> but not by-value objects?
>>
>> struct C {
>>   T t;
>> }
>>
>> C c1;
>> C c2 = c1;
>>
>> If T was a reference type, 'c1' and 'c2' now share state, and it's up to
>> the programmer to write code to prevent this.  Moreover, the D language
>> doesn't even give a hint as to whether T or a reference type or a value
>> type.  If T is a template parameter, it could be both.
> 
> Okay, reference types don't have value semantics. That's exactly what I
> would expect.

That sounds tautological, but many newcomers to D are surprised by
reference semantics when they expected value semantics.

> Why is it a problem?

Because reference types don't play well with RAII types.

Because unintentional object aliasing a problem orders of magnitude more
common than unintentional object slicing, and at least an order of
magnitude harder to detect and fix.

Because you can't correctly duplicate a multi-dimensional dynamic array
in D by using the built-in 'dup' property.

Because having two syntactically similar ways of creating user-defined
types with different features sets and different semantics is confusing,
 especially if you later decide that you need a struct to be a class and
all your copies turn into reference or vice versa.

> Because there is no explicit builtin
> copying mechanism for classes? If there were such, would it be a problem
> if copying were not the default?

What exactly do you have in mind?
Would it allow classes to correctly work with RAII types?
Would it prevent unintentional object aliasing?
Would it allow multi-dimensional arrays to be correctly duplicated?
Would it remove the need for both classes and structs in the language,
or at least the need to switch between the two?


-- 
Rainer Deyke - rainerd at eldwood.com