Inability to dup/~ for const arrays of class objects

[Jonathan M Davis]

On Tuesday, May 28, 2013 22:58:39 Ali Çehreli wrote:
> 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! ;)

Having const references or pointers is occasionally useful, but we wouldn't 
lose much IMHO if we lost them. Java got it backwards in that that's the 
_only_ kind of const that it has (via final). However, I don't know how 
feasible your suggestion is. Remember that there isn't really any difference 
between the reference and the object in the type system. When you mark a 
function as const, it's the this reference which is const. So, when you have a 
const C that you're operating on, it's the reference itself which is then the 
this reference and is passed around as const. As far as the type system is 
concerned, there's nothing else to _be_ const. So, you're asking for it to be 
treated as const as far as function calls go but treated as mutable otherwise, 
which goes against how const works. You're asking for a half-constness of 
sorts.

To make matters worse, what happens when you have a const object which has a 
reference as a member variable? e.g.

class C
{
    class D d;
}

const C c;

Because of the transitivity of const, d must be fully const, and yet with your 
suggestion, it isn't. Or if it is, we now have a situation where the constness 
of a reference depends on its context, and the compiler must keep track of its 
context in addition to its type in order to determine whether it's fully const 
or just half const.

So, while at first glance, I think that your suggestion makes sense 
conceptually, I think that it's going to fall apart when we get into the 
details.

I confess that for the most part, I've just given up and resigned myself to 
using Rebindable.

- Jonathan M Davis