www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to define a const?/static?/final? array.

reply Regan Heath <regan netwin.co.nz> writes:
I want to define an array whose contents cannot be modified. I tried 
const, final, static .. I searched the site and didn't find any help, 
'final' does not seem to be documented.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Regan Heath wrote:

 I want to define an array whose contents cannot be modified. I tried 
 const, final, static .. I searched the site and didn't find any help, 
 'final' does not seem to be documented.

 Regan

I suggested an approach to this a while ago. Simply wrap the array in a struct and use the operators. You can even use a template to save you from having to write the code again. -- -Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 10 Jun 2004 07:19:01 +0800, J Anderson 
<REMOVEanderson badmama.com.au> wrote:
 Regan Heath wrote:

 I want to define an array whose contents cannot be modified. I tried 
 const, final, static .. I searched the site and didn't find any help, 
 'final' does not seem to be documented.

 Regan

I suggested an approach to this a while ago. Simply wrap the array in a struct and use the operators. You can even use a template to save you from having to write the code again.

Eeeew! This should be simple, not complicated, and it should be intuitive. Why can't we have a keyword? Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Regan Heath wrote:

 On Thu, 10 Jun 2004 07:19:01 +0800, J Anderson 
 <REMOVEanderson badmama.com.au> wrote:

 Regan Heath wrote:

 I want to define an array whose contents cannot be modified. I tried 
 const, final, static .. I searched the site and didn't find any 
 help, 'final' does not seem to be documented.

 Regan

I suggested an approach to this a while ago. Simply wrap the array in a struct and use the operators. You can even use a template to save you from having to write the code again.

Eeeew! This should be simple, not complicated, and it should be intuitive. Why can't we have a keyword?

Because the programmer has to do something <g>.
 Regan

//module 1 template constArray(T) //This would be in another module { struct Array { private T [] array; static Array opCall(T [] array) { Array t; t.array = array; return t; } T opIndex(int i) { return array[i]; } int length() { return array.length; } } } Once you have it setup (you only ever need to do that once) it looks like: alias constArray!(int).Array constA; //module 2 void test(constA array) { int x = array[0]; //You just can't change the array variable (well at least not without force). } void main() { int [] a; a ~= 10; a ~= 30; test(constA(a)); //Ok there's a small bit of extra typing -> if D only had automatic boxing.... } -- -Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 10 Jun 2004 07:59:15 +0800, J Anderson 
<REMOVEanderson badmama.com.au> wrote:
 Regan Heath wrote:

 On Thu, 10 Jun 2004 07:19:01 +0800, J Anderson 
 <REMOVEanderson badmama.com.au> wrote:

 Regan Heath wrote:

 I want to define an array whose contents cannot be modified. I tried 
 const, final, static .. I searched the site and didn't find any help, 
 'final' does not seem to be documented.

 Regan

I suggested an approach to this a while ago. Simply wrap the array in a struct and use the operators. You can even use a template to save you from having to write the code again.

Eeeew! This should be simple, not complicated, and it should be intuitive. Why can't we have a keyword?

Because the programmer has to do something <g>.

Thanks for the example. I still think this is just plain wrong. In C/C++ it's this simple: const int pp[10] = { 0,1,2,3,4,5,6,7,8,9 }; void main( ) { pp[0] = 5; //error C2166: l-value specifies const object }
 Regan

//module 1 template constArray(T) //This would be in another module { struct Array { private T [] array; static Array opCall(T [] array) { Array t; t.array = array; return t; } T opIndex(int i) { return array[i]; } int length() { return array.length; } } } Once you have it setup (you only ever need to do that once) it looks like: alias constArray!(int).Array constA; //module 2 void test(constA array) { int x = array[0]; //You just can't change the array variable (well at least not without force). } void main() { int [] a; a ~= 10; a ~= 30; test(constA(a)); //Ok there's a small bit of extra typing -> if D only had automatic boxing.... }

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Regan Heath wrote:

 Thanks for the example. I still think this is just plain wrong. In 
 C/C++ it's this simple:

 const int pp[10] = {
     0,1,2,3,4,5,6,7,8,9
 };

 void main( )
 {
     pp[0] = 5; //error C2166: l-value specifies const object
 }

Oh, I though you where talking about parmeter const. You can do this: const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; void main( ) { pp[0] = 5; //This is ok in D } But you can change the values but not the length. So my first suggestion still stands. -- -Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 10 Jun 2004 08:19:41 +0800, J Anderson 
<REMOVEanderson badmama.com.au> wrote:
 Regan Heath wrote:

 Thanks for the example. I still think this is just plain wrong. In 
 C/C++ it's this simple:

 const int pp[10] = {
     0,1,2,3,4,5,6,7,8,9
 };

 void main( )
 {
     pp[0] = 5; //error C2166: l-value specifies const object
 }

Oh, I though you where talking about parmeter const. You can do this: const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; void main( ) { pp[0] = 5; //This is ok in D } But you can change the values but not the length.

So the 'const' applies to the array reference and not the data. Seems we need a new syntax to apply const to the array and/or the data, something like: const int const pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; //const array const data const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const data int const pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array I know, I have reversed the current syntax meaning. I think the above is how it should work however. Any other suggestions?
 So my first suggestion still stands.

It works.. it just seems wrong to be unable to do this with a keyword. Why can't we? I have read the posts about 'const' some people like it, some hate it, we have const for data types, but in the case of arrays (as above) it only applies to the reference, not the data itself. All I want to be able to do is specify some data that cannot be changed. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 10 Jun 2004 13:10:31 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Thu, 10 Jun 2004 08:19:41 +0800, J Anderson 
 <REMOVEanderson badmama.com.au> wrote:
 Regan Heath wrote:

 Thanks for the example. I still think this is just plain wrong. In 
 C/C++ it's this simple:

 const int pp[10] = {
     0,1,2,3,4,5,6,7,8,9
 };

 void main( )
 {
     pp[0] = 5; //error C2166: l-value specifies const object
 }

Oh, I though you where talking about parmeter const. You can do this: const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; void main( ) { pp[0] = 5; //This is ok in D } But you can change the values but not the length.

So the 'const' applies to the array reference and not the data. Seems we need a new syntax to apply const to the array and/or the data, something like: const int const pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; //const array const data const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const data int const pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array

Let me revice this, as it's not the D style... const int[] const pp = [ 0,1,2,3,4,5,6,7,8,9 ]; //const array const data const int[] pp = [ 0,1,2,3,4,5,6,7,8,9 ]; // const data int[] const pp = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array I think this syntax makes more sense.
 I know, I have reversed the current syntax meaning. I think the above is 
 how it should work however. Any other suggestions?

 So my first suggestion still stands.

It works.. it just seems wrong to be unable to do this with a keyword. Why can't we? I have read the posts about 'const' some people like it, some hate it, we have const for data types, but in the case of arrays (as above) it only applies to the reference, not the data itself. All I want to be able to do is specify some data that cannot be changed. Regan

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9ctjtys5a2sq9 digitalmars.com...
 On Thu, 10 Jun 2004 08:19:41 +0800, J Anderson
 <REMOVEanderson badmama.com.au> wrote:
 Regan Heath wrote:

 Thanks for the example. I still think this is just plain wrong. In
 C/C++ it's this simple:

 const int pp[10] = {
     0,1,2,3,4,5,6,7,8,9
 };

 void main( )
 {
     pp[0] = 5; //error C2166: l-value specifies const object
 }

Oh, I though you where talking about parmeter const. You can do this: const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; void main( ) { pp[0] = 5; //This is ok in D } But you can change the values but not the length.

So the 'const' applies to the array reference and not the data. Seems we need a new syntax to apply const to the array and/or the data, something like: const int const pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; //const array const data const int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const data int const pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array

Mind reader. :-)
 I know, I have reversed the current syntax meaning. I think the above is
 how it should work however. Any other suggestions?

 So my first suggestion still stands.

It works.. it just seems wrong to be unable to do this with a keyword.

Agreed
 Why can't we?

 I have read the posts about 'const' some people like it, some hate it, we
 have const for data types, but in the case of arrays (as above) it only
 applies to the reference, not the data itself.

Most of the debates - about using const (C++-sense) for DbC - are not germane to your requirement. I agree that something const (in the D sense) should be declarable in array form. Is there any need for the second or third of your pp definitions above? Perhaps the language should simply use const with arrays to mean const size + const data. Of course, if someone can offer good reasons against, then a more complex syntax may be required. I'd shy away from the const x const y syntax, if at all possible, however, simply because it's confusing. How about (and it's right off the top of my head, so ...): const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ]; //const array const data const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const data int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array ?
Jun 09 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Matthew" wrote
 Of course, if someone can offer good reasons against, then a more complex

 may be required. I'd shy away from the const x const y syntax, if at all
 possible, however, simply because it's confusing.

 How about (and it's right off the top of my head, so ...):

     const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const data
     const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
     int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

It would seem quite reasonable to, as others have noted, use the keyword 'final' as a storage class indicator. That is, where you have data that is read-only, immutable, constant (whatever one wishes to call it) the 'final' qualifier would do the "right thing". That includes isolating said data into a separate, potentially ROMable, section. Of course, this doesn't address the related debate regarding read-only function arguments ... Rather than "const const" syntax, what do you think about a "final const" combo instead? Personally, I don't care much for the parenthesized declaration ...
Jun 09 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 9 Jun 2004 19:05:07 -0700, Kris 
<someidiot earthlink.dot.dot.dot.net> wrote:
 "Matthew" wrote
 Of course, if someone can offer good reasons against, then a more 
 complex

 may be required. I'd shy away from the const x const y syntax, if at all
 possible, however, simply because it's confusing.

 How about (and it's right off the top of my head, so ...):

     const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const data
     const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
     int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

It would seem quite reasonable to, as others have noted, use the keyword 'final' as a storage class indicator.

I found final in my search for the right keyword, the online docs list it here... http://www.digitalmars.com/d/declaration.html StorageClass: abstract auto const deprecated final override static synchronized But does not describe what it means.
 That is, where you have data that is read-only, immutable, constant 
 (whatever one wishes to call it) the 'final' qualifier would do the 
 "right thing". That includes isolating said data into a separate, 
 potentially ROMable, section.

Sounds good. It's exactly what I was looking for.
 Of course, this doesn't address
 the related debate regarding read-only function arguments ...

 Rather than "const const" syntax, what do you think about a "final const"
 combo instead?

Why not just final. I cannot see why you'd want to declare it as final (meaning const data) and not const (meaning the array ref cannot change). Tho, there would still be a distinction between 'final' array data and a 'const' array, see example below... eg. final int[] pp = [ 0,1,2,3,4,5,6,7,9 ]; void main() { int[] aa = [ 1,2,3 ]; int[] bb; pp[0] = 0; //compile error pp = aa; //compile error aa[] = pp[0..3] //ok, aa's data is 'final', but aa is not 'const' aa[0] = 0; //compile error aa = bb; //ok, aa is not const }
 Personally, I don't care much for the parenthesized
 declaration ...

Too many parenthesis, not good, if we can avoid it, I say lets. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 10 Jun 2004 14:31:59 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Wed, 9 Jun 2004 19:05:07 -0700, Kris 
 <someidiot earthlink.dot.dot.dot.net> wrote:
 "Matthew" wrote
 Of course, if someone can offer good reasons against, then a more 
 complex

 may be required. I'd shy away from the const x const y syntax, if at 
 all
 possible, however, simply because it's confusing.

 How about (and it's right off the top of my head, so ...):

     const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const 
 data
     const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
     int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

It would seem quite reasonable to, as others have noted, use the keyword 'final' as a storage class indicator.

I found final in my search for the right keyword, the online docs list it here... http://www.digitalmars.com/d/declaration.html StorageClass: abstract auto const deprecated final override static synchronized But does not describe what it means.
 That is, where you have data that is read-only, immutable, constant 
 (whatever one wishes to call it) the 'final' qualifier would do the 
 "right thing". That includes isolating said data into a separate, 
 potentially ROMable, section.

Sounds good. It's exactly what I was looking for.
 Of course, this doesn't address
 the related debate regarding read-only function arguments ...

 Rather than "const const" syntax, what do you think about a "final 
 const"
 combo instead?

Why not just final. I cannot see why you'd want to declare it as final (meaning const data) and not const (meaning the array ref cannot change). Tho, there would still be a distinction between 'final' array data and a 'const' array, see example below... eg. final int[] pp = [ 0,1,2,3,4,5,6,7,9 ]; void main() { int[] aa = [ 1,2,3 ]; int[] bb; pp[0] = 0; //compile error pp = aa; //compile error aa[] = pp[0..3] //ok, aa's data is 'final', but aa is not 'const'

my wording here was a bit ambiguous, what I mean is: the data aa points to after this line (pp's data) is final, but aa does not become 'const'
        aa[0] = 0;       //compile error
 	aa = bb;         //ok, aa is not const
 }

 Personally, I don't care much for the parenthesized
 declaration ...

Too many parenthesis, not good, if we can avoid it, I say lets. Regan.

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 09 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:ca8fi6$1h5u$1 digitaldaemon.com...
 "Matthew" wrote
 Of course, if someone can offer good reasons against, then a more complex

 may be required. I'd shy away from the const x const y syntax, if at all
 possible, however, simply because it's confusing.

 How about (and it's right off the top of my head, so ...):

     const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const data
     const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
     int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

It would seem quite reasonable to, as others have noted, use the keyword 'final' as a storage class indicator. That is, where you have data that is read-only, immutable, constant (whatever one wishes to call it) the 'final' qualifier would do the "right thing". That includes isolating said data into a separate, potentially ROMable, section. Of course, this doesn't address the related debate regarding read-only function arguments ... Rather than "const const" syntax, what do you think about a "final const" combo instead? Personally, I don't care much for the parenthesized declaration ...

No, me neither. But I don't want us to have the double qualifier. What about final int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array meaning immutable array, immutable values?
Jun 09 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Matthew"  wrote
 What about

     final int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

 meaning immutable array, immutable values?

Hey; I'd be very happy if the compiler supported that right now <g>
Jun 09 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:ca8fi6$1h5u$1 digitaldaemon.com...
  

"Matthew" wrote
    

Of course, if someone can offer good reasons against, then a more complex
      

may be required. I'd shy away from the const x const y syntax, if at all
possible, however, simply because it's confusing.

How about (and it's right off the top of my head, so ...):

    const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const data
    const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
    int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array
      

'final' as a storage class indicator. That is, where you have data that is read-only, immutable, constant (whatever one wishes to call it) the 'final' qualifier would do the "right thing". That includes isolating said data into a separate, potentially ROMable, section. Of course, this doesn't address the related debate regarding read-only function arguments ... Rather than "const const" syntax, what do you think about a "final const" combo instead? Personally, I don't care much for the parenthesized declaration ...

No, me neither. But I don't want us to have the double qualifier. What about final int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array meaning immutable array, immutable values?

Just had a thought... Final with classes means you can't resize (ie inherit from them) them but you can still change the values so I think it would make more sense to do: final //Can't resize const //Can't resize or change values Otherwise you've got final meaning two different things, which is never a good idea. -- -Anderson: http://badmama.com.au/~anderson/
Jun 10 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 10 Jun 2004 19:18:06 +0800, J Anderson 
<REMOVEanderson badmama.com.au> wrote:

 Matthew wrote:

 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:ca8fi6$1h5u$1 digitaldaemon.com...

 "Matthew" wrote

 Of course, if someone can offer good reasons against, then a more 
 complex

 may be required. I'd shy away from the const x const y syntax, if at 
 all
 possible, however, simply because it's confusing.

 How about (and it's right off the top of my head, so ...):

    const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const 
 data
    const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
    int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

keyword 'final' as a storage class indicator. That is, where you have data that is read-only, immutable, constant (whatever one wishes to call it) the 'final' qualifier would do the "right thing". That includes isolating said data into a separate, potentially ROMable, section. Of course, this doesn't address the related debate regarding read-only function arguments ... Rather than "const const" syntax, what do you think about a "final const" combo instead? Personally, I don't care much for the parenthesized declaration ...

No, me neither. But I don't want us to have the double qualifier. What about final int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array meaning immutable array, immutable values?

Just had a thought... Final with classes means you can't resize (ie inherit from them) them

I never thought of "final" like that.. "final" to me mean "cannot be changed"
 but you can still change the values so I think it would make more sense 
 to do:

 final //Can't resize
 const //Can't resize or change values

 Otherwise you've got final meaning two different things, which is never 
 a good idea.

I always thought "final" meant "cannot change" i.e. a final class == a class that cannot be changed. a final method == a method that cannot be changed. a final array == an array that cannot be changed. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 10 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Regan Heath wrote:

 On Thu, 10 Jun 2004 19:18:06 +0800, J Anderson 
 <REMOVEanderson badmama.com.au> wrote:

 Matthew wrote:

 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:ca8fi6$1h5u$1 digitaldaemon.com...

 "Matthew" wrote

 Of course, if someone can offer good reasons against, then a more 
 complex

 may be required. I'd shy away from the const x const y syntax, if 
 at all
 possible, however, simply because it's confusing.

 How about (and it's right off the top of my head, so ...):

    const(int pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  //const array const 
 data
    const(int) pp[] = [ 0,1,2,3,4,5,6,7,8,9 ];  // const data
    int const(pp[]) = [ 0,1,2,3,4,5,6,7,8,9 ];  // const array

keyword 'final' as a storage class indicator. That is, where you have data that is read-only, immutable, constant (whatever one wishes to call it) the 'final' qualifier would do the "right thing". That includes isolating said data into a separate, potentially ROMable, section. Of course, this doesn't address the related debate regarding read-only function arguments ... Rather than "const const" syntax, what do you think about a "final const" combo instead? Personally, I don't care much for the parenthesized declaration ...

No, me neither. But I don't want us to have the double qualifier. What about final int pp[] = [ 0,1,2,3,4,5,6,7,8,9 ]; // const array meaning immutable array, immutable values?

Just had a thought... Final with classes means you can't resize (ie inherit from them) them

I never thought of "final" like that.. "final" to me mean "cannot be changed"
 but you can still change the values so I think it would make more 
 sense to do:

 final //Can't resize
 const //Can't resize or change values

 Otherwise you've got final meaning two different things, which is 
 never a good idea.

I always thought "final" meant "cannot change" i.e. a final class == a class that cannot be changed. a final method == a method that cannot be changed. a final array == an array that cannot be changed. Regan

Sorry, your right. -- -Anderson: http://badmama.com.au/~anderson/
Jun 10 2004
prev sibling parent reply Sam McCall <tunah.d tunah.net> writes:
Regan Heath wrote:

 but you can still change the values so I think it would make more 
 sense to do:

 final //Can't resize
 const //Can't resize or change values

 Otherwise you've got final meaning two different things, which is 
 never a good idea.

I always thought "final" meant "cannot change" i.e. a final class == a class that cannot be changed. a final method == a method that cannot be changed. a final array == an array that cannot be changed.

But your variable isn't the data in the array, it's a (pointer,length) pair, isn't it? In java at least, final is "shallow", so it would mean that you can't make it point to other data, and you can't change the length. I get the impression that (with careful placement ;-) const can be "deep". So I like
 final //Can't resize
 const //Can't resize or change values


Sam
Jun 13 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 13 Jun 2004 23:50:03 +1200, Sam McCall <tunah.d tunah.net> wrote:
 Regan Heath wrote:

 but you can still change the values so I think it would make more 
 sense to do:

 final //Can't resize
 const //Can't resize or change values

 Otherwise you've got final meaning two different things, which is 
 never a good idea.

I always thought "final" meant "cannot change" i.e. a final class == a class that cannot be changed. a final method == a method that cannot be changed. a final array == an array that cannot be changed.

But your variable isn't the data in the array, it's a (pointer,length) pair, isn't it?

Yep. That is the problem. I can only specify the array itself is constant, not the data, as I want to.
 In java at least, final is "shallow", so it would mean that you can't 
 make it point to other data, and you can't change the length.

That is how "const" works on D char[] (I believe).
 I get the impression that (with careful placement ;-) const can be 
 "deep".

It can? Currently? How?
 So I like
  >> final //Can't resize
  >> const //Can't resize or change values

Where else can "final" be used, and what does it mean when used there... We want it to have a consistent meaning. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
parent Sam McCall <tunah.d tunah.net> writes:
Regan Heath wrote:

 I get the impression that (with careful placement ;-) const can be 
 "deep".

It can? Currently? How?

 Where else can "final" be used, and what does it mean when used there...
 We want it to have a consistent meaning.

Sam
Jun 13 2004