Inability to dup/~ for const arrays of class objects

[Ali Çehreli]

On 05/28/2013 07:24 PM, Jonathan M Davis wrote:

 > On Tuesday, May 28, 2013 18:19:49 Ali Çehreli wrote:
 >> I remember the discussions on that topic and various syntax proposals
 >> but I don't remember why class variable assignment syntax would not 
work:
 >
 > The problem is that the type system does not differentiate between a 
class
 > object and a reference to a class object. The type refers explicitly 
to the
 > reference, not the object. It doesn't have the concept of a class object
 > separate from its reference

However, most of the operations on a class reference are relayed to the 
object:

   auto r = new C();
   r.foo();            // relayed to the object
   r.bar = 42;         // relayed to the object
   writeln(r);         // relayed to the object
   // ...              // etc.

With exception of assignment, which stays with the reference:

   r = new C();        // on the reference

How about the following two rules, which do not require any syntax 
change. Let's make it so that there are two kinds of type checks on a 
class reference:

1) For operations that involve the object, perform the type check as it 
is today.

2) The assignment operation is type-checked specially:

   const: Allow the assignment for any type on the right-hand side)

   immutable: Allow the assignment for only immutable on the right-hand side

   mutable: Allow the assignment for only mutable on the right-hand side

Of course this throws out the current behavior of non-mutable references 
being non-rebindable, but I think non-rebindable references are 
overrated. Even in C and C++, most of the time it is the data that is 
const. For example, nobody takes 'const char * const' parameters. Yes, 
it is helpful in theory, but programmers simply define the parameter as 
'const char *'. (Or 'char const *' if they are more purist. :) )

It seems simple enough but perhaps it is too difficult to implement at 
this point. Only Kenji can tell! ;)

Ali