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

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

"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
> 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
>
> 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?

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

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

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/

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
>>>>
>>> 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
>>>>
>>> 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?
>>
>
> 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/

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
>>>>>
>>>> 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
>>>>>
>>>> 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?
>>>
>>
>> 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/

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

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/

Regan Heath wrote:

>> I get the impression that (with careful placement ;-) const can be "deep".
> 
> 
> It can? Currently? How?
Er, I meant the accepted meaning of const as it's used in C++.

> Where else can "final" be used, and what does it mean when used there...
> We want it to have a consistent meaning.
Wouldn't have a clue, sorry ;-)
Sam