Bug 5984 – add new keywords objconst and objimmutable to make it possible to declare mutable reference variables referencing const or immutable class instances

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.

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

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

(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.

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.