keywords "objconst" and "objimmutable" vs. const(Object) ref

[Michel Fortin]

On 2011-05-17 20:00:55 -0400, Christopher the Magnificent 
<ultimatemacfanatic at 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 at michelf.com
http://michelf.com/