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

[Christopher the Magnificent]

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

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