www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5984] New: add new keywords obj_const and obj_immutable to make it possible to declare mutable reference variables referencing const or immutable class instances

reply d-bugmail puremagic.com writes:
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



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: -------
May 11 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5984


kennytm gmail.com changed:

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



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: -------
May 11 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5984




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.


 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: -------
May 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5984





 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: -------
May 13 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5984




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?





 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: -------
May 13 2011