June 02, 2005
In article <d7nra6$291a$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>What we all want to have is simple:
>"by using const for arrays and pointers we want to make
>some methods of const types 'private' - not accessible". This is it.

Actually, this would work for classes as well.


Sean


June 02, 2005
Regan Heath wrote:
> Ok, side question, assume we're going to use 'const' (or any keyword) for  array contents (something I've asked for in the past), how do we write it?
> 
I like
const char[] bob;

since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes.
In D "const char[] bob", means that the contents of bob cannot be altered, the reference can't be changed, and you cannot slice out a chunk of bob unless you are slicing into another const char[].
Well it could mean that :)  It could also mean anything else!

Brad
June 02, 2005
"Brad Beveridge" <brad@somewhere.net> wrote in message news:d7ntg7$2b5e$1@digitaldaemon.com...
> Regan Heath wrote:
>> Ok, side question, assume we're going to use 'const' (or any keyword) for array contents (something I've asked for in the past), how do we write it?
>>
> I like
> const char[] bob;
>
> since we aren't C++, I don't think that we should split hairs quite so
> much about where the const (or readonly) keyword goes.
> In D "const char[] bob", means that the contents of bob cannot be altered,
> the reference can't be changed, and you cannot slice out a chunk of bob
> unless you are slicing into another const char[].
> Well it could mean that :)  It could also mean anything else!
>
> Brad

Yep, only one:
"the reference can't be changed"
I think this is too strict.

const char[] Dolli = "McArtur"; // fine
/// mariage happens
                   Dolli = "O'Connor"; // shoud be also fine.
/// but attempt  to break Dolli's "private parts" ((C) Booch) - to change
/// value iself will be an erro:r
                     Dolli[0] = '\0'; /// ERROR






June 02, 2005
On Thu, 02 Jun 2005 14:25:28 -0700, Brad Beveridge <brad@somewhere.net> wrote:
> Regan Heath wrote:
>> Ok, side question, assume we're going to use 'const' (or any keyword) for  array contents (something I've asked for in the past), how do we write it?
>>
> I like
> const char[] bob;
>
> since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes.

I wasn't concerned so much with 'where' to type the keyword, but rather whether we need to be able to:

1 - have a constant reference, to non-constant data
2 - have a non-constant reference, to constant data
3 - have a constant reference, to constant data

If we need all of them, then:

"const char[] bob" - to me, means const ref (as it currently does in D)
"char[const] bob"  - (my fav suggestion so far) to me, means const data
"const char[const] bob" - const ref, const data

> In D "const char[] bob", means that the contents of bob cannot be altered, the reference can't be changed

So, you believe we only need option #3 above?

> , and you cannot slice out a chunk of bob unless you are slicing into another const char[].

That would be illegal, surely?

"another const char[]" is a constant reference, so you cannot change it - unless you were thinking we might lift this restriction at initialisation time, eg.

const char[] abc = "abc";
const char[] bob = abc[0..2];

> Well it could mean that :)  It could also mean anything else!

Yeah, but we do have to make some temporary decisions in order to come to a temporary solution/idea in order to test it, before we can make any decisions.

Regan
June 02, 2005
On Thu, 2 Jun 2005 14:40:33 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> "Brad Beveridge" <brad@somewhere.net> wrote in message
> news:d7ntg7$2b5e$1@digitaldaemon.com...
>> Regan Heath wrote:
>>> Ok, side question, assume we're going to use 'const' (or any keyword) for
>>> array contents (something I've asked for in the past), how do we write
>>> it?
>>>
>> I like
>> const char[] bob;
>>
>> since we aren't C++, I don't think that we should split hairs quite so
>> much about where the const (or readonly) keyword goes.
>> In D "const char[] bob", means that the contents of bob cannot be altered,
>> the reference can't be changed, and you cannot slice out a chunk of bob
>> unless you are slicing into another const char[].
>> Well it could mean that :)  It could also mean anything else!
>>
>> Brad
>
> Yep, only one:
> "the reference can't be changed"
> I think this is too strict.
>
> const char[] Dolli = "McArtur"; // fine
> /// mariage happens
>                    Dolli = "O'Connor"; // shoud be also fine.
> /// but attempt  to break Dolli's "private parts" ((C) Booch) - to change
> /// value iself will be an erro:r
>                      Dolli[0] = '\0'; /// ERROR

I don't understand what you're saying. Which of these, if any, do you think we need to be able to do:

1 - have a constant reference, to non-constant data
2 - have a non-constant reference, to constant data
3 - have a constant reference, to constant data

Bear in mind, when I say:

"constant reference" I mean a char[] which cannot be assigned to, or it's length changed. eg.

char[] foo = "bar";
foo = foo[1..3]; //illegal
foo.length = foo.length + 10; //illegal
foo[0] = 'a' //ok

"constant data" I mean a char[] whose referenced data cannot be modified, eg.

char[] foo = "bar";
foo = foo[1..3]; //ok
foo.length = foo.length + 10; //ok
foo[0] = 'a' //illegal

Regan
June 02, 2005
Regan Heath wrote:

> 1 - have a constant reference, to non-constant data
> 2 - have a non-constant reference, to constant data
> 3 - have a constant reference, to constant data
> 
> If we need all of them, then:
> 
> "const char[] bob" - to me, means const ref (as it currently does in D)
> "char[const] bob"  - (my fav suggestion so far) to me, means const data
> "const char[const] bob" - const ref, const data
> 
>> In D "const char[] bob", means that the contents of bob cannot be  altered, the reference can't be changed
> 
> 
> So, you believe we only need option #3 above?
I think so, though I don't feel strongly - we may need #2.  I don't see that we need #1.
Sorry, I don't like "char[const] bob", simply because I feel it is too close to the AA syntax, eg, what is "char[const int] bob" going to do?

> 
>> , and you cannot slice out a chunk of bob unless you are slicing into  another const char[].
> 
> 
> That would be illegal, surely?
> 
> "another const char[]" is a constant reference, so you cannot change it -  unless you were thinking we might lift this restriction at initialisation  time, eg.
I was thinking more along the lines of
const char[] str = "This is a string";

void foo (const char[] f){...}
void foo (char[] f){...}

foo(str[0..4]); // slices and calls the foo(const char[]) func

Brad
June 02, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsrrjkrfx23k2f5@nrage.netwin.co.nz...
> On Thu, 2 Jun 2005 14:40:33 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> "Brad Beveridge" <brad@somewhere.net> wrote in message news:d7ntg7$2b5e$1@digitaldaemon.com...
>>> Regan Heath wrote:
>>>> Ok, side question, assume we're going to use 'const' (or any keyword)
>>>> for
>>>> array contents (something I've asked for in the past), how do we write
>>>> it?
>>>>
>>> I like
>>> const char[] bob;
>>>
>>> since we aren't C++, I don't think that we should split hairs quite so
>>> much about where the const (or readonly) keyword goes.
>>> In D "const char[] bob", means that the contents of bob cannot be
>>> altered,
>>> the reference can't be changed, and you cannot slice out a chunk of bob
>>> unless you are slicing into another const char[].
>>> Well it could mean that :)  It could also mean anything else!
>>>
>>> Brad
>>
>> Yep, only one:
>> "the reference can't be changed"
>> I think this is too strict.
>>
>> const char[] Dolli = "McArtur"; // fine
>> /// mariage happens
>>                    Dolli = "O'Connor"; // shoud be also fine.
>> /// but attempt  to break Dolli's "private parts" ((C) Booch) - to change
>> /// value iself will be an erro:r
>>                      Dolli[0] = '\0'; /// ERROR
>
> I don't understand what you're saying. Which of these, if any, do you think we need to be able to do:
>
> 1 - have a constant reference, to non-constant data
> 2 - have a non-constant reference, to constant data
> 3 - have a constant reference, to constant data

I mean #2.

As #1 ( and #3 ) you can protect by exisiting mechanisms in D -
you can always wrap references in something.
Or you can choose to use in, inout, etc to passing references.

But values they are referring to are not protected.
There are no ways to implement #2 in D now .

Makes sense?


>
> Bear in mind, when I say:
>
> "constant reference" I mean a char[] which cannot be assigned to, or it's length changed. eg.
>
> char[] foo = "bar";
> foo = foo[1..3]; //illegal
> foo.length = foo.length + 10; //illegal
> foo[0] = 'a' //ok
>
> "constant data" I mean a char[] whose referenced data cannot be modified, eg.
>
> char[] foo = "bar";
> foo = foo[1..3]; //ok
> foo.length = foo.length + 10; //ok
> foo[0] = 'a' //illegal
>
> Regan


June 02, 2005
On Thu, 02 Jun 2005 15:07:42 -0700, Brad Beveridge <brad@somewhere.net> wrote:
> Regan Heath wrote:
>
>> 1 - have a constant reference, to non-constant data
>> 2 - have a non-constant reference, to constant data
>> 3 - have a constant reference, to constant data
>>  If we need all of them, then:
>>  "const char[] bob" - to me, means const ref (as it currently does in D)
>> "char[const] bob"  - (my fav suggestion so far) to me, means const data
>> "const char[const] bob" - const ref, const data
>>
>>> In D "const char[] bob", means that the contents of bob cannot be  altered, the reference can't be changed
>>   So, you believe we only need option #3 above?
> I think so, though I don't feel strongly - we may need #2.  I don't see that we need #1.

I cannot think of a specific use off the top of my head for #1, but, I would err on the side of caution and, presuming no reason against, make it possible.

> Sorry, I don't like "char[const] bob", simply because I feel it is too close to the AA syntax, eg, what is "char[const int] bob" going to do?

Good question. Options are AFAICS:

- illegal (raising the question of how to define constant data for an AA)
- keys to AA are const (not sure what that might mean yet)

I don't like either option myself..

So, exploring a syntax for enabling all 3 options, it looks like we have:

#1 const char[] x
#2 char[] const y;
#3 const char[] const z;

Presuming we need all 3, any problems with this syntax?

If not, the next question this raises is how/when is 'y' initialised. I recall Matthew (I think - don't quote me) asking for a 'const' that would allow initialisation in a constructor (class, or static module).

>>> , and you cannot slice out a chunk of bob unless you are slicing into  another const char[].
>>   That would be illegal, surely?
>>  "another const char[]" is a constant reference, so you cannot change it -  unless you were thinking we might lift this restriction at initialisation  time, eg.
> I was thinking more along the lines of
> const char[] str = "This is a string";
>
> void foo (const char[] f){...}
> void foo (char[] f){...}
>
> foo(str[0..4]); // slices and calls the foo(const char[]) func

Ahh, that is in fact the same thing :)

The slice is creating a new array, which is then initialised. So the rule might be "const arrays can be assigned only when they are initialised."

The passing of the new const char[] into the function would follow normal rules from then on, as in, it's a const array so it's fine. Aside: AS non const char[] could be passed to this function, as non const can implicitly be promoted to const (but not vice-versa).

Regan
June 02, 2005
On Thu, 2 Jun 2005 15:16:00 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsrrjkrfx23k2f5@nrage.netwin.co.nz...
>> I don't understand what you're saying. Which of these, if any, do you
>> think we need to be able to do:
>>
>> 1 - have a constant reference, to non-constant data
>> 2 - have a non-constant reference, to constant data
>> 3 - have a constant reference, to constant data
>
> I mean #2.
>
> As #1 ( and #3 ) you can protect by exisiting mechanisms in D -
> you can always wrap references in something.
> Or you can choose to use in, inout, etc to passing references.

Yet 'in' does not prevent you from changing the parameter (a copy of the real reference) so you often get bugs where the programmer has desired change, implemented it, seen no errors from the compiler, and yet it fails. It would be nice to prevent this.

It seems a simple change to have the compiler treat 'in' as 'const in' erroring on changes to the parameter itself.

> But values they are referring to are not protected.
> There are no ways to implement #2 in D now .
>
> Makes sense?

Perfect. I'm just not convinced we don't want all 3, yet.

Regan
June 02, 2005
On Fri, 03 Jun 2005 10:20:53 +1200, Regan Heath wrote:

[snip]

> So, exploring a syntax for enabling all 3 options, it looks like we have:
> 
> #1 const char[] x
> #2 char[] const y;
> #3 const char[] const z;

I'm getting confused now; sorry. Are these three things mean ...

 #1 I can't modify the reference but I can modify the data.
 #2 I can modify the reference but I can't modify the data.
 #3 I can't modify the reference and I can't modify the data.


-- 
Derek
Melbourne, Australia
3/06/2005 8:53:25 AM