I've been following the const stuff to learn about it and start thinking of applications for it. I've made a post about a suggested syntax for declaring different parts const, but I'm starting to wander why a constant reference with mutable data is needed. Currently const is transitive so a const ref would make const data. I do not see a need for syntax change if we don't need this.

What is the need for a X const x which lets you change the object in x but not reassign it to another X?

Jesse Phillips wrote:
> I've been following the const stuff to learn about it and start thinking of applications for it. I've made a post about a suggested syntax for declaring different parts const, but I'm starting to wander why a constant reference with mutable data is needed. Currently const is transitive so a const ref would make const data. I do not see a need for syntax change if we don't need this.
> 
> What is the need for a X const x which lets you change the object in x but not reassign it to another X?

It's helpful when you have complex functions that don't want to rebind their arguments but need to modify them, for one.

A common example is a shared buffer: you don't want some class replacing the buffer, since you want everyone using the same one all the time, and you might copy the reference for ease of use. But you want to modify its contents.

On 11/30/07, Jesse Phillips <jessekphillips@gmail.com> wrote:
> What is the need for a X const x which lets you change the object in x but not reassign it to another X?

It's not needed at all. What you're describing is "head const", and Walter just ditched it.

Head-constness is a purely local thing. It's always possible to do without it.

For reference-objects (i.e. classes) you only need
    mutable ref, mutable data
    mutable ref, const data
    const ref, const data

because const is transitive in D.

For non-reference-objects (i.e. everything else) you only need
    mutable data
    const data

(...and the same holds for invariant)

On Sat, 1 Dec 2007 06:17:16 +0000, Janice Caron wrote:

> On 11/30/07, Jesse Phillips <jessekphillips@gmail.com> wrote:
>> What is the need for a X const x which lets you change the object in x but not reassign it to another X?
> 
> It's not needed at all. What you're describing is "head const", and Walter just ditched it.
> 
> Head-constness is a purely local thing. It's always possible to do without it.

What is a D code example that catches inadverant reallocations at compile time?

   char[] Buffer = new char[MAXBUFSIZE];
   . . .
   Buffer ~= "abc";   // Oops. This is not allowed because
                      // the designer wanted to avoid
                      // excess memory allocations.
   . . .



-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On 12/1/07, Derek Parnell <derek@psych.ward> wrote:
> What is a D code example that catches inadverant reallocations at compile time?

Just don't do it. Head const is a purely local thing. The designer of a function knows what it's supposed to do, and if they make it do something stupid, it's a bug

>    char[] Buffer = new char[MAXBUFSIZE];
>    . . .
>    Buffer ~= "abc";   // Oops. This is not allowed because
>                       // the designer wanted to avoid
>                       // excess memory allocations.

Const is transitive in D. Walter says that's not going to change. You just have to deal with it.

On Sat, 1 Dec 2007 08:33:25 +0000, Janice Caron wrote:

> On 12/1/07, Derek Parnell <derek@psych.ward> wrote:
>> What is a D code example that catches inadverant reallocations at compile time?
> 
> Just don't do it. Head const is a purely local thing. The designer of a function knows what it's supposed to do, and if they make it do something stupid, it's a bug


(a) D can't to X
(b) To try to do X in D is stupid
(c) X is a valid paradigm

therefore

(d) Wanting D to do X is stupid.

I get it now.

>>    char[] Buffer = new char[MAXBUFSIZE];
>>    . . .
>>    Buffer ~= "abc";   // Oops. This is not allowed because
>>                       // the designer wanted to avoid
>>                       // excess memory allocations.
> 
> Const is transitive in D. Walter says that's not going to change. You just have to deal with it.

Walter, the BD of D, has been known to change his mind.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On 12/1/07, Derek Parnell <derek@psych.ward> wrote:
> (a) D can't to X
> (b) To try to do X in D is stupid
> (c) X is a valid paradigm

I think the point is the case for head-const as a useful paradigm is very weak. To use your own example. All you have to do is rewrite it like this:

    char[MAXBUFSIZE] buffer;
    ...
    buffer ~= "abc"; // Error

Or, if you're passing it to a function, wrap it in a class or struct

    class Buffer
    {
        char[MAXBUFSIZE] buffer;
    }

    f(Buffer b)
    {
        buffer ~= "abc"; // Error
    }

> Walter, the BD of D, has been known to change his mind.

Sorry, I don't understand what BD of D means.

In any case, I think Walter will change his mind if there is a strong enough case. If this newsgroup shows near-unanimous support, and real-world test cases can be demonstrated. That doesn't seem to be the case here.

On 12/2/07, Janice Caron <caron800@googlemail.com> wrote:
>     f(Buffer b)
>     {
>         buffer ~= "abc"; // Error
>     }

     f(Buffer b)
     {
         b.buffer ~= "abc"; // Also error :-)
     }

Janice Caron wrote:
>> Walter, the BD of D, has been known to change his mind.
> 
> Sorry, I don't understand what BD of D means.

BD is presumably short for "benevolent dictator".

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Janice Caron wrote:
> On 12/1/07, Derek Parnell <derek@psych.ward> wrote:
>> What is a D code example that catches inadverant reallocations at compile
>> time?
> 
> Just don't do it. Head const is a purely local thing. The designer of
> a function knows what it's supposed to do, and if they make it do
> something stupid, it's a bug

That's right. Const-correctness is a thing that becomes necessary when crossing API boundaries, it is of only minor utility for local references only.