Greetings all.  First time poster here.

By way of introduction, my name is Christopher.  I've been fascinated with D for a few years now.  My main programming language has been Python, but I have used and studied many programming languages to some extent.  I love to design things, like houses, pipe organs, and even computer languages.

What I like about D is that it seems to strike the right balance of allowing fairly high level programming with static typing yet still permitting access on several progressively deeper levels to the nuts and bolts of the computer.  I also love D's module system and its dynamic arrays, to name just a few things.

Now down to business.  I want to talk about const and immutable.  There are 5,256 posts in this list containing the text "const" so I just this topic is discussed often.

We all know that object references are really implemented as pointers to the object's data structures on the heap.

When we say "const Object a", we declare a constant variable pointing to a constant data structure.  Sometimes we need to declare a modifiable variable pointing to a constant data structure.

I propose the syntax "objconst Object a" to declare modifiable reference variable pointing to a const object data structure, and "objimmutable Object A" for modifiable reference variable pointing to immutable object data structure:
	
	objimmutable Object 	a = cast(immutable) new Object();
	objconst Object		b = new Object();

	b = a;	// b is modifiable
	
	// ILLEGAL: b references constant data structure
	b.someVariable = newValue;

These could also be used in the parenthesized way:

	objconst(Object)	a;
	objconst(Object)*[1]	a_array;
	
	a = new Object();
	a_array[0] = &a;
	*a_array[0] = new Object(); // change a to a different object

Now I understand that another syntax has been nominated to do this job which is the const(Object)ref syntax.  I dislike that syntax because "const(Object)" means a constant variable referencing a constant data structure, and "const(Object)ref" LOOKS like it should be a reference to a variable of type "const(Object)" -- to me it suggests a variable referencing a constant variable referencing a constant data structure. "const(Object)ref" suggests TWO levels of pointers, but that is not the meaning being ascribed thereunto.

I picked the keywords "objconst" and "objimmutable" to suggest that the object data structure (hence the "obj" prefix) is immutable or const. This was a compromise between brevity and descriptiveness.  I suppose they could also go "constobj" and "immutableobj".

Another reason why the objconst/objimmutable syntax is better than "const(Object)ref" is that it requires fewer tokens to parse and to type -- this makes it easier to read:

	const(Object) ref 	a; 	// 5 tokens in the type
	objconst Object 	a; 	// only 2 tokens

I submitted this idea to the bug tracking system as a feature request, but I also want to hear what people have to say about it on here.

What do you think guys, Mr. Bright?  And what do you like better--"objconst" and "objimmutable" or "constobj" and "immutableobj"?

--Christopher

This is what Rebindable(T) is for:

http://www.digitalmars.com/d/2.0/phobos/std_typecons.html

On 5/17/11 6:17 PM, %u wrote:
> This is what Rebindable(T) is for:
>
> http://www.digitalmars.com/d/2.0/phobos/std_typecons.html


Thanks for the reference, but to me, rebindable feels like a hack.  My opinion is that D deserves to have such an integral feature as mutable references to const object data structures baked into the language with a standard syntax, rather than added on using templates in an imported module.

That a rebindable template can implement this functionality at all is a testament to the power and flexibility of D, but this really ought to be a core language feature.

Christopher the Magnificent Wrote:

> Greetings all.  First time poster here.
> 
> By way of introduction, my name is Christopher.  I've been fascinated with D for a few years now.  My main programming language has been Python, but I have used and studied many programming languages to some extent.  I love to design things, like houses, pipe organs, and even computer languages.

Hello, and welcome.

> Now I understand that another syntax has been nominated to do this job which is the const(Object)ref syntax.  I dislike that syntax because "const(Object)" means a constant variable referencing a constant data structure, and "const(Object)ref" LOOKS like it should be a reference to a variable of type "const(Object)" -- to me it suggests a variable referencing a constant variable referencing a constant data structure. "const(Object)ref" suggests TWO levels of pointers, but that is not the meaning being ascribed thereunto.

Syntax has definitely been a major problem for this feature. Walter's stance has been that he has tried many times to get the semantics and syntax to work and has given up. michelf (Sorry don't know his real name) has created a branch which implements the syntax you are against. As this is a change Walter is skeptical of it will take time to review.

Now as for your distaste, I believe the intent is to make a valid declaration:

Object ref foobar;

Meaning that you are exposing the reference or address itself. However I think there might be more to it when considering generic code which would suggest these should also be valid forms:

void function(T)(const(T) ref thing);

const(int) ref foo;
const(myStruct) ref bar;
const(int*) ref bared;

But that would suggest D has a reference type, and it doesn't. So in any case, this isn't simple and I'm not really sure how well const(Object) ref stands up to this kind of question.

On 5/17/11 7:26 PM, Jesse Phillips wrote:
> Christopher the Magnificent Wrote:
>
>> Greetings all.  First time poster here.
>>
>> By way of introduction, my name is Christopher.  I've been fascinated
>> with D for a few years now.  My main programming language has been
>> Python, but I have used and studied many programming languages to some
>> extent.  I love to design things, like houses, pipe organs, and even
>> computer languages.
>
> Hello, and welcome.
>
>> Now I understand that another syntax has been nominated to do this job
>> which is the const(Object)ref syntax.  I dislike that syntax because
>> "const(Object)" means a constant variable referencing a constant data
>> structure, and "const(Object)ref" LOOKS like it should be a reference to
>> a variable of type "const(Object)" -- to me it suggests a variable
>> referencing a constant variable referencing a constant data structure.
>> "const(Object)ref" suggests TWO levels of pointers, but that is not the
>> meaning being ascribed thereunto.
>
> Syntax has definitely been a major problem for this feature. Walter's stance has been that he has tried many times to get the semantics and syntax to work and has given up. michelf (Sorry don't know his real name) has created a branch which implements the syntax you are against. As this is a change Walter is skeptical of it will take time to review.
>
> Now as for your distaste, I believe the intent is to make a valid declaration:
>
> Object ref foobar;
>
> Meaning that you are exposing the reference or address itself. However I think there might be more to it when considering generic code which would suggest these should also be valid forms:
>
> void function(T)(const(T) ref thing);
>
> const(int) ref foo;
> const(myStruct) ref bar;
> const(int*) ref bared;
>
> But that would suggest D has a reference type, and it doesn't. So in any case, this isn't simple and I'm not really sure how well const(Object) ref stands up to this kind of question.

Thanks for the background, Jesse Phillips.  Do you have any thoughts on my proposed objconst/objimmutable syntax, as to whether you think it is readable, intuitive, and just whether you like it or don't like it?

On 2011-05-17 20:00:55 -0400, Christopher the Magnificent <ultimatemacfanatic@gmail.com> said:

> Now I understand that another syntax has been nominated to do this job which is the const(Object)ref syntax.

I don't think there has been any official word on that. But many people have shown support for it.

> I dislike that syntax because "const(Object)" means a constant variable referencing a constant data structure, and "const(Object)ref" LOOKS like it should be a reference to a variable of type "const(Object)" -- to me it suggests a variable referencing a constant variable referencing a constant data structure. "const(Object)ref" suggests TWO levels of pointers, but that is not the meaning being ascribed thereunto.

But ask yourself this: why does "Object ref" looks like a double reference to you? I'll guess an answer: because of previous knowledge of the language that says to you that "Object" is always implicitly a reference type.

The basic idea behind the const(Object)ref proposal is to change the meaning of "Object" to become a shortcut for "Object ref". In other word, the "ref" part is always there, and if you omit it, it's added implicitly for you. Try to look at thing from a this new perspective and it'll fit better.

> I picked the keywords "objconst" and "objimmutable" to suggest that the object data structure (hence the "obj" prefix) is immutable or const. This was a compromise between brevity and descriptiveness.  I suppose they could also go "constobj" and "immutableobj".

Personally, I like better the feel of const(Object)ref than any of these keywords. For one thing, it doesn't require any new keyword. For another, it's perfectly in line with how you do it for pointers. Also, it'll work for 'shared' and 'inout' too (once 'inout' works properly).

Working like pointers has other advantages too: it allow you to transpose your understanding of type deduction and type matching in templates and is-expressions freely between pointers and objects references. Making the syntax different adds a barrier to applying your experience of one to the other, this barrier simply does not exist with const(Object)ref because the syntax is similar enough to const(S)*.

> Another reason why the objconst/objimmutable syntax is better than "const(Object)ref" is that it requires fewer tokens to parse and to type -- this makes it easier to read:
> 
> 	const(Object) ref 	a; 	// 5 tokens in the type
> 	objconst Object 	a; 	// only 2 tokens

Easier to type, granted. Easier to read, I'm not so sure; mimicking the existing syntax for pointer makes things more coherent.

Easier to parse, I'm not too sure about that either, but it's quite irrelevant anyway. What's difficult is implementing the corresponding semantics in the compiler. The main reason being that, unlike the common perception people have, it's only the compiler backend that deals with class types the same way it deals with pointers. Type attributes (const, immutable, shared, inout) are enforced in the frontend, and the frontend has no separate type for an object and an object reference, and thus no way to attach attributes to the reference separately from the main object type. As the entirety of the frontend is written with that assumption in mind, it's hard to overcome without rewriting a very big portion of the code.

Now, I figured a way around that, one that Walter will hopefully accept once he find enough time to review my patch. If he thinks another syntax (such as yours) is more appropriate, it should a pretty trivial change. But my preference remains with const(Object)ref.

Thanks for your input Christopher, and welcome to D.

- - -

For reference, here's my pull request for const(Object)ref: <https://github.com/D-Programming-Language/dmd/pull/3>.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

So how do functions which take such a parameter look like?

void bar(ref Foo a, const(Foo) ref b) { }

or

void bar(ref Foo a, ref const(Foo) b) { }

Christopher the Magnificent Wrote:

> Thanks for the background, Jesse Phillips.  Do you have any thoughts on my proposed objconst/objimmutable syntax, as to whether you think it is readable, intuitive, and just whether you like it or don't like it?

I'm going to go with 	Michel's reply. The const(Object) ref is more consistent with pointers and the smashed keyword looks weird to me.

Mr. Fortin, thank you for your thorough response.  I have just a few comments.

On 5/17/11 9:07 PM, Michel Fortin wrote:
> On 2011-05-17 20:00:55 -0400, Christopher the Magnificent
> <ultimatemacfanatic@gmail.com> said:
>
>> Now I understand that another syntax has been nominated to do this job
>> which is the const(Object)ref syntax.
>
> I don't think there has been any official word on that. But many people
> have shown support for it.
>
>> I dislike that syntax because "const(Object)" means a constant
>> variable referencing a constant data structure, and "const(Object)ref"
>> LOOKS like it should be a reference to a variable of type
>> "const(Object)" -- to me it suggests a variable referencing a constant
>> variable referencing a constant data structure. "const(Object)ref"
>> suggests TWO levels of pointers, but that is not the meaning being
>> ascribed thereunto.
>
> But ask yourself this: why does "Object ref" looks like a double
> reference to you? I'll guess an answer: because of previous knowledge of
> the language that says to you that "Object" is always implicitly a
> reference type.

I think that previous knowledge of the language ought to inform the direction of future additions.  My previous knowledge of D says that, as in Java, a variable of type Object (where Object is a class-based type) is a reference type.

> The basic idea behind the const(Object)ref proposal is to change the
> meaning of "Object" to become a shortcut for "Object ref".

I disagree that this is something that should be changed.

In other
> word, the "ref" part is always there, and if you omit it, it's added
> implicitly for you.

I am personally opposed to giving "Object" and "Object ref" the exact same meaning.  This strikes me as confusing because we have been conditioned to understand that "Object" means reference to data structure for an object, but in the second instance "Object" refers to the data structure itself.  Inconsistent and confusing, say I.

Try to look at thing from a this new perspective and
> it'll fit better.
>
>> I picked the keywords "objconst" and "objimmutable" to suggest that
>> the object data structure (hence the "obj" prefix) is immutable or
>> const. This was a compromise between brevity and descriptiveness. I
>> suppose they could also go "constobj" and "immutableobj".
>
> Personally, I like better the feel of const(Object)ref than any of these
> keywords. For one thing, it doesn't require any new keyword.

I would argue that adding new keywords is a better way to go because we're not giving the "ref" keyword two distinct but very subtly different uses.

> For
> another, it's perfectly in line with how you do it for pointers. Also,
> it'll work for 'shared' and 'inout' too (once 'inout' works properly).

Are you saying that objconst and objimmutable would NOT work for shared and inout?  Why is that?

> Working like pointers has other advantages too: it allow you to
> transpose your understanding of type deduction and type matching in
> templates and is-expressions freely between pointers and objects
> references. Making the syntax different adds a barrier to applying your
> experience of one to the other, this barrier simply does not exist with
> const(Object)ref because the syntax is similar enough to const(S)*.
>
>> Another reason why the objconst/objimmutable syntax is better than
>> "const(Object)ref" is that it requires fewer tokens to parse and to
>> type -- this makes it easier to read:
>>
>> const(Object) ref a; // 5 tokens in the type
>> objconst Object a; // only 2 tokens
>
> Easier to type, granted. Easier to read, I'm not so sure; mimicking the
> existing syntax for pointer makes things more coherent.
>
> Easier to parse, I'm not too sure about that either, but it's quite
> irrelevant anyway. What's difficult is implementing the corresponding
> semantics in the compiler. The main reason being that, unlike the common
> perception people have, it's only the compiler backend that deals with
> class types the same way it deals with pointers. Type attributes (const,
> immutable, shared, inout) are enforced in the frontend, and the frontend
> has no separate type for an object and an object reference, and thus no
> way to attach attributes to the reference separately from the main
> object type. As the entirety of the frontend is written with that
> assumption in mind, it's hard to overcome without rewriting a very big
> portion of the code.

When I said easier to parse, I meant by human eyes.  Sorry, I should have made that clearer.

> Now, I figured a way around that, one that Walter will hopefully accept
> once he find enough time to review my patch. If he thinks another syntax
> (such as yours) is more appropriate, it should a pretty trivial change.
> But my preference remains with const(Object)ref.

I still like my proposal best, BUT I would rather see your syntax be selected over mine than for us to be left with no better option than to use Rebindable to get mutable references to constant object data structures.

> Thanks for your input Christopher, and welcome to D.

You're welcome.  I'm glad to be joining the D community.  Thanks for taking the time to write a thoughtful reply to my postings.

>
> - - -
>
> For reference, here's my pull request for const(Object)ref:
> <https://github.com/D-Programming-Language/dmd/pull/3>.
>
>

const(deref(Object)) ref obj;
deref(Object) a; //hehe.