http://d.puremagic.com/issues/show_bug.cgi?id=5984

           Summary: add new keywords obj_const and obj_immutable to make
                    it possible to declare mutable reference variables
                    referencing const or immutable class instances
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: ultimatemacfanatic@gmail.com


--- Comment #0 from Christopher the Magnificent <ultimatemacfanatic@gmail.com> 2011-05-11 13:08:28 PDT ---
Suppose we have struct A:

struct A
{
    ...
}


Next, suppose we have a function that takes two immutable pointers to As
(plural of A)

immutable(A)*
func(immutable A* a1, immutable A* a2)
{
    ...
}


Finally suppose that we need a variable that can alternately point to the object pointed to by a1 or a2 (which and be changed later during the function. This is straightforward in D.  It looks like this:



immutable(A)*
func(immutable A* a1, immutable A* a2)
{
    //TAKE NOTE OF THIS LINE--DECLARES MUTABLE POINTER TO IMMUTABLE STRUCT
OBJECT
    immutable(A)* a_ptr = null;

    a_ptr = a1;

    <do stuff with a_ptr>

    if (<somecondition>)
        a_ptr = a2;

    <do more stuff with a_ptr>

    return a_ptr;
}

This is all fine and good.  But what happens if A is not a struct but a class? Well the pointer syntax becomes implied and <immutable(A)> means IMMUTABLE reference variable pointing to immutable object which is *NOT WHAT IS NEEDED*.

There is no equivalent code to my knowledge that I can write in D that does the EXACT same thing with class object variables that I just did with struct pointers above while preserving the compiler's enforcment of the constness or immutability of objects referenced by a1 and a2!

Yes, I could have pointer variables pointing to object reference variables a1 and a2 which reference (implicitly point to without actual pointer syntax) the actual heap objects; however, that double indirection (first explicit with pointers and second implicit with the object reference variable) is inefficient and somewhat confusing.  At worst, the D language, by its lacking the appropriate constness-typing solution is actively encouraging the programmer to simply cast away the constness or immutability of objects referenced by a1 and a2 to gain the simplicity of storing reference to a1's object or a2's object in a fully mutable reference variable (e.g. <A a_ptr;>)

THE SOLUTION:

The solution is two new keywords "obj_const" and "obj_immutable" or some variation on those names which when applied as either a storage specifier (as in <obj_const ClassName variableName;>) or as a type modifier (as in <obj_immutable(ClassName) variableName;>) would create a MUTABLE REFERENCE VARIABLE REFERRING TO A CONST OR IMMUTABLE CLASS OBJECT.

This would extend to declaring arrays of mutable references to const or immutable objects like so

    obj_const(ClassName)[] myArray;

    myArray.length = 2;

    immutable ClassName immutableRef = cast(immutable) new
ClassName(<argument>);
    const ClassName constRef = new ClassName(<argument>);

    obj_const ClassName myMutableRef = immutableRef;

    myArray[0] = myMutableRef;

    myMutableRef = constRef;

    myArray[1] = myMutableRef

This new functionality would be backwards compatible with the existing meaning of <const(ClassName)> and <immutable(ClassName)> which would continue to declare an un-modifiable reference variable pointing to a const or immutable class object.

The only compatibility issue I can see is with variables, types, and functions clashing with the new keywords, which I expect would be unheard of, given the highly specific nature of these keywords; it is very unlikely for there to be any significant name clashes.

POSSIBLE KEYWORDS:

objconst, objimmutable
obj_const, obj_immutable
tailconst, tailimmutable
tail_const, tail_immutable

CONCLUSION:

Hopefully, these additions can add to the expressiveness and power of the D language and increase the ability of the compiler to enforce constness and immutability in ways that are useful to the programmer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5984


kennytm@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm@gmail.com


--- Comment #1 from kennytm@gmail.com 2011-05-11 13:19:54 PDT ---
How is this better than the 'const(Object) ref' syntax*?

    class A { ... }

    immutable(A) func(immutable A a1, immutable A a2) {
        immutable(A) ref a_ptr = null;
        ...
    }

and

    const(ClassName)ref[] myArray;

Actually there is already std.typecons.Rebindable which mostly works (uglily):

    class A { ... }

    immutable(A) func(immutable A a1, immutable A a2) {
        Rebindable!(immutable(A)) a_ptr = null;
        ...
    }

and

    Rebindable!(const(ClassName))[] myArray;
    myArray.length = 1;
    myArray[0] = constant_object;
    myArray ~= rebindable(constant_object);

*: https://github.com/D-Programming-Language/dmd/pull/3

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5984



--- Comment #2 from Christopher the Magnificent <ultimatemacfanatic@gmail.com> 2011-05-13 10:09:30 PDT ---
Where do I find the "const(Object) ref" syntax described?  I've never run across it in the D Language Reference.  Point me to some info about this particular syntax and then I'll be able to comment on how my own syntax may be superior.

(In reply to comment #1)
> How is this better than the 'const(Object) ref' syntax*?
> 
>     class A { ... }
> 
>     immutable(A) func(immutable A a1, immutable A a2) {
>         immutable(A) ref a_ptr = null;
>         ...
>     }
> 
> and
> 
>     const(ClassName)ref[] myArray;
> 
> Actually there is already std.typecons.Rebindable which mostly works (uglily):
> 
>     class A { ... }
> 
>     immutable(A) func(immutable A a1, immutable A a2) {
>         Rebindable!(immutable(A)) a_ptr = null;
>         ...
>     }
> 
> and
> 
>     Rebindable!(const(ClassName))[] myArray;
>     myArray.length = 1;
>     myArray[0] = constant_object;
>     myArray ~= rebindable(constant_object);
> 
> *: https://github.com/D-Programming-Language/dmd/pull/3

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5984



--- Comment #3 from kennytm@gmail.com 2011-05-13 11:43:14 PDT ---
(In reply to comment #2)
> Where do I find the "const(Object) ref" syntax described?  I've never run across it in the D Language Reference.  Point me to some info about this particular syntax and then I'll be able to comment on how my own syntax may be superior.
> 

This is a third-party proposal, and isn't even approved. You won't find it in the official reference ;)

See bug 5325 and the huge thread in http://www.digitalmars.com/d/archives/digitalmars/D/const_Object_ref_is_here_123681.html. You may also search for "tail const" to find a lot of previous discussions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5984



--- Comment #4 from Christopher the Magnificent <ultimatemacfanatic@gmail.com> 2011-05-13 15:29:16 PDT ---
Okay, thanks for bringing me up to speed with the existing "const(Object) ref"
stuff.

Here's my thought.  The const(Object) ref syntax, while getting the job done, is undesirable because it highjacks an existing syntax in such a way that previous meaning of what is being added to is lost.

Here's what I mean.

        const(MyObject)   myVar;

In the above thing, "const(Object)" is the type, and it means a constant variable referencing a constant object of class MyObject.

Now we have

        const(MyObject) ref    myVar2;

Is myVar2 a reference to an entity of type "const(MyObject)"?  In other words, is myVar a *reference to a constant variable referencing to a constant object of class MyObject*?

Nope!  But I submit that that's exactly what this syntax suggests to a person of average intuition.

This "ref" syntax implies two levels of pointers as in "a ref to a const ref to a const object".  This is not what the syntax actually does.  When you have the ref after it then the "const(MyObject)" part suddenly stops meaning "constant variable referencing constant object" and starts meaning "constant object". Therefore, the syntax is to me misleading and liable to be misunderstood.

Second, in the mailing list I read someone wanting to do this:

        MyObject ref    myVar;  // ref keyword ensures that MyObject is a
class; error if MyObject is a struct

This seems to encourage people to indiscriminately insert keyword "ref" and litter their D code with syntactic fluff that, while providing a sanity check, doesn't actually change the meaning of correctly written code, making stuff harder to read, and all this rather than requiring people to just look up the interface and double check that something is indeed a class before they start to use it.

There may be a benefit to instituting a compiler check that asserts something is a struct vs. a class, but I don't think using the keyword ref is the best way to do this.  I have my own idea about this--just permit the optional prefixing of the type names with "class", "struct", or "enum" and the compiler doubles checks it.  This is a better solution because those three keywords reinforce what they're doing, rather than restating the obvious (that the variable is storing a reference).

Now look at my syntax:

        // the following two are equivalent
        objconst MyObject   myVar;

        const(objimmutable(MyObject))*  myPtr;  // pointer to const variable
referencing immutable object

        objconst(MyObject)[]  myArray;   // array of mutable variables
referencing const objects

ADVANTAGES:
* This syntax is visually cleaner
    * Parentheses may be omitted for the simple case above--not so with
<const(MyObject) ref>
    * Requires only one keyword instead of two.
* It doesn't appear to change the meaning of existing syntax like
<const(MyObject) ref> does
* When the syntax is used, it always has an effect upon the meaning of the
program.  Does not turn into fluff.
* It is more specific in its usage and it its effect than the alternative.
* It solves a single problem well, rather than trying to do several things at
once in an obscure fashion.

BY THE WAY
I think I like the variety of keywords without the underscores best.  Do you
like my keywords better with or without underscores?



(In reply to comment #3)
> (In reply to comment #2)
> > Where do I find the "const(Object) ref" syntax described?  I've never run across it in the D Language Reference.  Point me to some info about this particular syntax and then I'll be able to comment on how my own syntax may be superior.
> > 
> 
> This is a third-party proposal, and isn't even approved. You won't find it in the official reference ;)
> 
> See bug 5325 and the huge thread in http://www.digitalmars.com/d/archives/digitalmars/D/const_Object_ref_is_here_123681.html. You may also search for "tail const" to find a lot of previous discussions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------