www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'final' variables

reply Lionello Lunesu <lio lunesu.remove.com> writes:
I've been trying to follow the thread on the const/final/invariant 
extensions but I have to wonder: how useful are final variables?

final int i = 2;

This would mean: 'i' cannot be rebound to another value. Right? So this 
final is actually C++'s const.

void func( final int i )
{
   //i is not const but cannot be set either
}

Also here, it's like C++'s const, but with the _removed_ benefit of 
restricting the accepted types. Is this correct?

What's the use of "final" for variables? I'm saying "for variables" 
because for methods the benefit is only too clear.

L.

PS. I've started a new thread because this isn't a reply to any 
particular post.
Mar 20 2007
next sibling parent reply Tyler Knott <tywebmail mailcity.com> writes:
Lionello Lunesu Wrote:

 What's the use of "final" for variables? I'm saying "for variables" 
 because for methods the benefit is only too clear.
 


Because the "const" keyword is being repurposed for read-only references to
mutable or non-mutable data, we need a new keyword for non-mutable variables. 
"final" fills that purpose nicely.  If the value of the variable is known at
compile time, the compiler can constant-fold away the memory access to that
variable for a small speed boost.  If the value is only determinable at
runtime, that can still allow the compiler to make some optimizations that
would not be possible with mutable variables.
Mar 20 2007
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Tyler Knott Wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables?  I'm saying "for 
 variables" because for methods the benefit is only too clear.


 
 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, we need a new 
 keyword for non-mutable variables.


<snip>

C++ manages with const for both, so why can't D?  What circumstance is there in
which either keyword would be valid with different meanings?

Stewart.
Mar 20 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Stewart Gordon wrote:

 Tyler Knott Wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables?  I'm saying "for 
 variables" because for methods the benefit is only too clear.


 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, we need a new 
 keyword for non-mutable variables.


 <snip>
 
 C++ manages with const for both, so why can't D?
 What circumstance is there in which either keyword would be valid
 with different meanings?


Some D reference types do not have the pointer qualifier, so this C++ 
declaration:

     int const * const x;

could not be directly reproduced in D, except for maybe:

     int const [] const x;

which is horrifying :-)  And it still doesn't address the issue of class 
references.


Sean
Mar 20 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Stewart Gordon wrote:

 Tyler Knott Wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables?  I'm saying "for variables" 
 because for methods the benefit is only too clear.


 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, we need a new keyword for 
 non-mutable variables.


 <snip>

 C++ manages with const for both, so why can't D?


  > What circumstance is there in which either keyword would be valid
  > with different meanings?
 
 Some D reference types do not have the pointer qualifier, so this C++ 
 declaration:
 
     int const * const x;
 
 could not be directly reproduced in D, except for maybe:
 
     int const [] const x;
 
 which is horrifying :-)  And it still doesn't address the issue of class 
 references.


I _swear_ I hadn't seen this post when posted one with the same syntax 
in it :o).

Andrei
Mar 20 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Stewart Gordon wrote:

 Tyler Knott Wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables?  I'm saying "for 
 variables" because for methods the benefit is only too clear.


 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, we need a new 
 keyword for non-mutable variables.


 <snip>
 
 C++ manages with const for both, so why can't D?  What circumstance is there
in which either keyword would be valid with different meanings?


If you apply "const" to a class reference, how would you determine which 
of {reference,object} the const applies to?

- If to the reference only, you can't express the constness of objects.
- If to the object only, you can't express non-rebindability of the 
reference. (C++ doesn't have this problem, since the only references it 
has are implicitly final all by themselves)
- If to both, you can only express constness of objects by 
simultaneously disallowing the reference to be rebound. Not nice.

I think that covers all cases (except 'neither', but that simply doesn't 
make any sense ;) ).
Mar 20 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Mar 2007 16:52:14 +0100, Frits van Bommel wrote:


 Stewart Gordon wrote:

 Tyler Knott Wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables?  I'm saying "for 
 variables" because for methods the benefit is only too clear.


 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, we need a new 
 keyword for non-mutable variables.


 <snip>
 
 C++ manages with const for both, so why can't D?  What circumstance is there
in which either keyword would be valid with different meanings?


 
 If you apply "const" to a class reference, how would you determine which 
 of {reference,object} the const applies to?
 
 - If to the reference only, you can't express the constness of objects.
 - If to the object only, you can't express non-rebindability of the 
 reference. (C++ doesn't have this problem, since the only references it 
 has are implicitly final all by themselves)
 - If to both, you can only express constness of objects by 
 simultaneously disallowing the reference to be rebound. Not nice.
 
 I think that covers all cases (except 'neither', but that simply doesn't 
 make any sense ;) ).


What happens with ...

   final const Foo f;
   invariant Foo f;

do either of these mean that both the reference and the object is not to be
modified?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/03/2007 10:13:28 AM
Mar 20 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Derek Parnell wrote:

 On Tue, 20 Mar 2007 16:52:14 +0100, Frits van Bommel wrote:
 

 Stewart Gordon wrote:

 Tyler Knott Wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables?  I'm saying "for 
 variables" because for methods the benefit is only too clear.


 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, we need a new 
 keyword for non-mutable variables.


 <snip>

 C++ manages with const for both, so why can't D?  What circumstance is there
in which either keyword would be valid with different meanings?


 If you apply "const" to a class reference, how would you determine which 
 of {reference,object} the const applies to?

 - If to the reference only, you can't express the constness of objects.
 - If to the object only, you can't express non-rebindability of the 
 reference. (C++ doesn't have this problem, since the only references it 
 has are implicitly final all by themselves)
 - If to both, you can only express constness of objects by 
 simultaneously disallowing the reference to be rebound. Not nice.

 I think that covers all cases (except 'neither', but that simply doesn't 
 make any sense ;) ).


 
 What happens with ...
 
    final const Foo f;
    invariant Foo f;
 
 do either of these mean that both the reference and the object is not to be
 modified?
 


In the first decleration, the referance cannot be changed, and provides only an
immutable 
view into the object, so the object cannot be modified /by/ the referance 'f'. 
It is a 
final variable, of type const Foo.

In the second decleration, the referance is mutable, but the object is
guaranteed 
unchanging.  It is a standard variable, of type invariant Foo.

If you wanted to absolute guarantee that 'f' itself never changes, and the
underlying 
object does likewise, it'd be: final invariant Foo f;

If I'm following all this right...

-- Chris Nicholson-Sauls
Mar 20 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Mar 2007 18:19:29 -0600, Chris Nicholson-Sauls wrote:


 If you wanted to absolute guarantee that 'f' itself never changes, and the
underlying 
 object does likewise, it'd be: final invariant Foo f;


At which point I'd wish for a text macro system to make "guard" the alias
for "final invariant" <G>

   guard Foo f;

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/03/2007 10:34:41 AM
Mar 20 2007
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Tyler Knott wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables? I'm saying "for variables" 
 because for methods the benefit is only too clear.


 
 Because the "const" keyword is being repurposed for read-only references to
mutable or non-mutable data, 


...which I want, very much!


 we need a new keyword for non-mutable variables.


That's my question: do we actually need that? Examples are welcomed.


 "final" fills that purpose nicely.  If the value of the variable is 


known at compile time, the compiler can constant-fold away the memory 
access to that variable for a small speed boost.  If the value is only 
determinable at runtime, that can still allow the compiler to make some 
optimizations that would not be possible with mutable variables.

This is the part I'm not sure about. As with C++'s "const", I don't 
think the compiler can conclude anything and therefor it can't optimize 
anything. A "final" variable is not constant.

L.
Mar 20 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:

 Tyler Knott wrote:

 Lionello Lunesu Wrote:

 What's the use of "final" for variables? I'm saying "for variables" 
 because for methods the benefit is only too clear.


 Because the "const" keyword is being repurposed for read-only 
 references to mutable or non-mutable data, 


 
 ...which I want, very much!
 

 we need a new keyword for non-mutable variables.


 
 That's my question: do we actually need that? Examples are welcomed.
 
  > "final" fills that purpose nicely.  If the value of the variable is 
 known at compile time, the compiler can constant-fold away the memory 
 access to that variable for a small speed boost.  If the value is only 
 determinable at runtime, that can still allow the compiler to make some 
 optimizations that would not be possible with mutable variables.
 
 This is the part I'm not sure about. As with C++'s "const", I don't 
 think the compiler can conclude anything and therefor it can't optimize 
 anything. A "final" variable is not constant.


final int x = 42;

Change that :o).


Andrei
Mar 20 2007
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 This is the part I'm not sure about. As with C++'s "const", I don't 
 think the compiler can conclude anything and therefor it can't 
 optimize anything. A "final" variable is not constant.


 
 final int x = 42;
 
 Change that :o).
 
 Andrei


How does this interact with CTFE for variables that are declared as 
const. With previous versions of the compiler, I know that it would try 
to constant-fold this code, resulting in an inlined constant from the 
result of the CTFE:

    const int abc = kaboom();

That code shouts out to me (and to the compiler) that the kaboom() 
method MUST be evaluated at compile-time. But this code is not nearly so 
clear:

    final int xyz = shabam();

Just because xyz can't be re-bound after its initial assignment doesn't 
necessarily mean that shabam() should be executed at compile-time. With 
the new const/final/invariant semantics, how will the compiler know when 
to perform constant-folding (or, I suppose, "final-folding") on functions?

--benji
Mar 20 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 This is the part I'm not sure about. As with C++'s "const", I don't 
 think the compiler can conclude anything and therefor it can't 
 optimize anything. A "final" variable is not constant.


 final int x = 42;

 Change that :o).

 Andrei


 
 How does this interact with CTFE for variables that are declared as 
 const. With previous versions of the compiler, I know that it would try 
 to constant-fold this code, resulting in an inlined constant from the 
 result of the CTFE:
 
    const int abc = kaboom();
 
 That code shouts out to me (and to the compiler) that the kaboom() 
 method MUST be evaluated at compile-time. But this code is not nearly so 
 clear:
 
    final int xyz = shabam();
 
 Just because xyz can't be re-bound after its initial assignment doesn't 
 necessarily mean that shabam() should be executed at compile-time. With 
 the new const/final/invariant semantics, how will the compiler know when 
 to perform constant-folding (or, I suppose, "final-folding") on functions?


Undecided at this time. At least "static final" will take care of that - 
you can't dynamically-initialize statics.

Andrei
Mar 20 2007
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 This is the part I'm not sure about. As with C++'s "const", I don't 
 think the compiler can conclude anything and therefor it can't 
 optimize anything. A "final" variable is not constant.


 final int x = 42;

 Change that :o).

 Andrei


 How does this interact with CTFE for variables that are declared as 
 const. With previous versions of the compiler, I know that it would 
 try to constant-fold this code, resulting in an inlined constant from 
 the result of the CTFE:

    const int abc = kaboom();

 That code shouts out to me (and to the compiler) that the kaboom() 
 method MUST be evaluated at compile-time. But this code is not nearly 
 so clear:

    final int xyz = shabam();

 Just because xyz can't be re-bound after its initial assignment 
 doesn't necessarily mean that shabam() should be executed at 
 compile-time. With the new const/final/invariant semantics, how will 
 the compiler know when to perform constant-folding (or, I suppose, 
 "final-folding") on functions?


 
 Undecided at this time. At least "static final" will take care of that - 
 you can't dynamically-initialize statics.
 
 Andrei


Damn. I always thought "static final" in Java was a sloppy kludge for 
what should have been "const".

--benji
Mar 20 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Damn. I always thought "static final" in Java was a sloppy kludge for 
 what should have been "const".


It is. This is because Java lacks the notion of const for 
indirectly-referred data, which is the interesting case.

Andrei
Mar 20 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 This is the part I'm not sure about. As with C++'s "const", I don't 
 think the compiler can conclude anything and therefor it can't 
 optimize anything. A "final" variable is not constant.


 final int x = 42;

 Change that :o).

 Andrei


 How does this interact with CTFE for variables that are declared as 
 const. With previous versions of the compiler, I know that it would 
 try to constant-fold this code, resulting in an inlined constant from 
 the result of the CTFE:

    const int abc = kaboom();

 That code shouts out to me (and to the compiler) that the kaboom() 
 method MUST be evaluated at compile-time. But this code is not nearly 
 so clear:

    final int xyz = shabam();

 Just because xyz can't be re-bound after its initial assignment 
 doesn't necessarily mean that shabam() should be executed at 
 compile-time. With the new const/final/invariant semantics, how will 
 the compiler know when to perform constant-folding (or, I suppose, 
 "final-folding") on functions?


 
 Undecided at this time. At least "static final" will take care of that - 
 you can't dynamically-initialize statics.


But presumably that would allocate space for the variable in the data 
segment.

int CTFE_function1(int x)
{
	static final y = CTFE_function2(x);
}

And that's a really clumsy construction for something which occurs so 
frequently.
Mar 23 2007
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Benji Smith wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 This is the part I'm not sure about. As with C++'s "const", I don't 
 think the compiler can conclude anything and therefor it can't 
 optimize anything. A "final" variable is not constant.


 final int x = 42;

 Change that :o).

 Andrei


 
 How does this interact with CTFE for variables that are declared as 
 const. With previous versions of the compiler, I know that it would try 
 to constant-fold this code, resulting in an inlined constant from the 
 result of the CTFE:
 
    const int abc = kaboom();
 
 That code shouts out to me (and to the compiler) that the kaboom() 
 method MUST be evaluated at compile-time. But this code is not nearly so 
 clear:
 
    final int xyz = shabam();
 
 Just because xyz can't be re-bound after its initial assignment doesn't 
 necessarily mean that shabam() should be executed at compile-time. With 
 the new const/final/invariant semantics, how will the compiler know when 
 to perform constant-folding (or, I suppose, "final-folding") on functions?


const would still exist, right? So you'd just keep using "const int x = 
...". The _only_ purpose of "final int y" is for code clarity, you don't 
have to scan a whole function to see what happens to that variable, 
since nothing will happen to it.

L.


L.
Mar 20 2007
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 final int x = 42;
 
 Change that :o).


Not fair! You meant "const" :)

L.
Mar 20 2007
prev sibling next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:

 I've been trying to follow the thread on the const/final/invariant 
 extensions but I have to wonder: how useful are final variables?
 
 final int i = 2;
 
 This would mean: 'i' cannot be rebound to another value. Right? So this 
 final is actually C++'s const.
 
 void func( final int i )
 {
   //i is not const but cannot be set either
 }
 
 Also here, it's like C++'s const, but with the _removed_ benefit of 
 restricting the accepted types. Is this correct?
 
 What's the use of "final" for variables? I'm saying "for variables" 
 because for methods the benefit is only too clear.
 
 L.
 
 PS. I've started a new thread because this isn't a reply to any 
 particular post.


Very simple.

void Fun(const char[] s)
{
   ...
}

Cannot modify s's content, but can rebind it. If the programmer wants to 
not rebind, then she writes:

void Fun(final const char[] s)
{
   ...
}


Andrei
Mar 20 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Lionello Lunesu wrote:

 I've been trying to follow the thread on the const/final/invariant 
 extensions but I have to wonder: how useful are final variables?

 final int i = 2;

 This would mean: 'i' cannot be rebound to another value. Right? So 
 this final is actually C++'s const.

 void func( final int i )
 {
   //i is not const but cannot be set either
 }

 Also here, it's like C++'s const, but with the _removed_ benefit of 
 restricting the accepted types. Is this correct?

 What's the use of "final" for variables? I'm saying "for variables" 
 because for methods the benefit is only too clear.

 L.

 PS. I've started a new thread because this isn't a reply to any 
 particular post.


 
 Very simple.
 
 void Fun(const char[] s)
 {
   ...
 }
 
 Cannot modify s's content, but can rebind it. If the programmer wants to 
 not rebind, then she writes:
 
 void Fun(final const char[] s)
 {
   ...
 }


I understand, but what's the point of telling the compiler "I don't want 
to rebind this variable"? It doesn't seem like an optimization hint. 
Like telling "func(const int i)" in C++ doesn't actually do anything. 
You just type more. And if you later want to rebind 'i' you'll have to 
change the interface. Lose-lose?

L.
Mar 20 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:

 Andrei Alexandrescu (See Website For Email) wrote:

 Lionello Lunesu wrote:

 I've been trying to follow the thread on the const/final/invariant 
 extensions but I have to wonder: how useful are final variables?

 final int i = 2;

 This would mean: 'i' cannot be rebound to another value. Right? So 
 this final is actually C++'s const.

 void func( final int i )
 {
   //i is not const but cannot be set either
 }

 Also here, it's like C++'s const, but with the _removed_ benefit of 
 restricting the accepted types. Is this correct?

 What's the use of "final" for variables? I'm saying "for variables" 
 because for methods the benefit is only too clear.

 L.

 PS. I've started a new thread because this isn't a reply to any 
 particular post.


 Very simple.

 void Fun(const char[] s)
 {
   ...
 }

 Cannot modify s's content, but can rebind it. If the programmer wants 
 to not rebind, then she writes:

 void Fun(final const char[] s)
 {
   ...
 }


 
 I understand, but what's the point of telling the compiler "I don't want 
 to rebind this variable"? It doesn't seem like an optimization hint. 
 Like telling "func(const int i)" in C++ doesn't actually do anything. 
 You just type more. And if you later want to rebind 'i' you'll have to 
 change the interface. Lose-lose?


Many people, including yours truly, appreciate the ability of 
automatically checking their assumptions or desires.


Andrei
Mar 20 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 I understand, but what's the point of telling the compiler "I don't want 
 to rebind this variable"? It doesn't seem like an optimization hint. 
 Like telling "func(const int i)" in C++ doesn't actually do anything. 
 You just type more.


Final is handy for a number of things:
1) For class members, it would indicate that a class is not mutable once 
it's constructed. Probably most classes are like this, and so it's a 
handy way to document it.
2) Andrei pointed out to me that one can often replace:
	auto x = initializer;
with:
	final x = initializer;
to indicate in a block of code that x will never be reassigned. This 
aids in understanding the code. It's a style I intend to adopt.
3) For cases like:
	const char[] s = "hello";
is it s that's not rebindable, or is the data that s is pointing to 
immutable? This never fails to confuse me (in C++), so I like to be able 
to say which it is in a clear manner.


 And if you later want to rebind 'i' you'll have to 
 change the interface. Lose-lose?


Although final is specified in the interface, it is not part of the 
interface. It only affects the implementation of the interface. You'll 
be able to change it without affecting any users of the interface.
Mar 20 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Lionello Lunesu wrote:

 I understand, but what's the point of telling the compiler "I don't 
 want to rebind this variable"? It doesn't seem like an optimization 
 hint. Like telling "func(const int i)" in C++ doesn't actually do 
 anything. You just type more.


 
 Final is handy for a number of things:
 1) For class members, it would indicate that a class is not mutable once 
 it's constructed. Probably most classes are like this, and so it's a 
 handy way to document it.
 2) Andrei pointed out to me that one can often replace:
     auto x = initializer;
 with:
     final x = initializer;
 to indicate in a block of code that x will never be reassigned. This 
 aids in understanding the code. It's a style I intend to adopt.


And the compiler will have an excellent opportunity to optimize the code 
(e.g. it can enregister "x" without fear). It's a win-win deal. Believe 
me. I'm not wearing a tie.


 3) For cases like:
     const char[] s = "hello";
 is it s that's not rebindable, or is the data that s is pointing to 
 immutable? This never fails to confuse me (in C++), so I like to be able 
 to say which it is in a clear manner.


What still needs to be decided here is whether we want to automatically 
make s final too when seen in a data definition. This is a hack for 
existing code's sake, and also because many people actually mean to make 
final const strings more often than just nonfinal const strings. 
Probably final can be inferred via simple flow analysis at low or no 
extra cost, which would please everyone.


Andrei
Mar 20 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Mar 2007 14:03:34 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


 Walter Bright wrote:

 Lionello Lunesu wrote:

 I understand, but what's the point of telling the compiler "I don't 
 want to rebind this variable"? It doesn't seem like an optimization 
 hint. Like telling "func(const int i)" in C++ doesn't actually do 
 anything. You just type more.


 
 Final is handy for a number of things:
 1) For class members, it would indicate that a class is not mutable once 
 it's constructed. Probably most classes are like this, and so it's a 
 handy way to document it.
 2) Andrei pointed out to me that one can often replace:
     auto x = initializer;
 with:
     final x = initializer;
 to indicate in a block of code that x will never be reassigned. This 
 aids in understanding the code. It's a style I intend to adopt.


 
 And the compiler will have an excellent opportunity to optimize the code 
 (e.g. it can enregister "x" without fear). It's a win-win deal. Believe 
 me. I'm not wearing a tie.
 

 3) For cases like:
     const char[] s = "hello";
 is it s that's not rebindable, or is the data that s is pointing to 
 immutable? This never fails to confuse me (in C++), so I like to be able 
 to say which it is in a clear manner.


 
 What still needs to be decided here is whether we want to automatically 
 make s final too when seen in a data definition. This is a hack for 
 existing code's sake, and also because many people actually mean to make 
 final const strings more often than just nonfinal const strings. 
 Probably final can be inferred via simple flow analysis at low or no 
 extra cost, which would please everyone.


Now I know (really) that new keywords are *to be avoided at all costs*, but
this looks nice to me ...

   literal char[] s = "hello";

meaning that neither 's' can be changed nor can the data 's' points to.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/03/2007 10:17:22 AM
Mar 20 2007
prev sibling next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:etpb8a$bfe$1 digitalmars.com...

 Lionello Lunesu wrote:

 I understand, but what's the point of telling the compiler "I don't want 
 to rebind this variable"? It doesn't seem like an optimization hint. Like 
 telling "func(const int i)" in C++ doesn't actually do anything. You just 
 type more.


 Final is handy for a number of things:
 1) For class members, it would indicate that a class is not mutable once 
 it's constructed. Probably most classes are like this, and so it's a handy 
 way to document it.





 2) Andrei pointed out to me that one can often replace:
 auto x = initializer;
 with:
 final x = initializer;
 to indicate in a block of code that x will never be reassigned. This aids 
 in understanding the code. It's a style I intend to adopt.


OK, "final x" means that you can skip big pieces of code, knowing that "x" 
will not change.


 3) For cases like:
 const char[] s = "hello";
 is it s that's not rebindable, or is the data that s is pointing to 
 immutable? This never fails to confuse me (in C++), so I like to be able 
 to say which it is in a clear manner.


Will "const" imply "final"? Hm, guess not, since you'll still want to write 
"const char* x" and reassign 'x' later. But now I'm thinking too much C++.


 And if you later want to rebind 'i' you'll have to change the interface. 
 Lose-lose?


 Although final is specified in the interface, it is not part of the 
 interface. It only affects the implementation of the interface. You'll be 
 able to change it without affecting any users of the interface.


Ah, that alone makes it a lot more practical than (half of) C++'s const. 
Good one.

Some good points. Thanks.

L.
Mar 20 2007
prev sibling parent James Dennett <jdennett acm.org> writes:
Walter Bright wrote:

 Lionello Lunesu wrote:

 And if you later want to rebind 'i' you'll have to change the
 interface. Lose-lose?


 
 Although final is specified in the interface, it is not part of the
 interface. It only affects the implementation of the interface. You'll
 be able to change it without affecting any users of the interface.


Same as C++ here then: the declaration

void f(int);

is identical to

void f(int const);

though in the corresponding definition the implementation
gets checking that it doesn't alter its local copy of the
int if it uses const qualification.  It's quite legal
(and quite common) to declare

void f(int);

and then define f as

void f(int const value)
{
  // ... code here can't accidentally change the local value
}

-- James
Mar 20 2007
prev sibling parent "David B. Held" <dheld codelogicconsulting.com> writes:
Lionello Lunesu wrote:

 I've been trying to follow the thread on the const/final/invariant 
 extensions but I have to wonder: how useful are final variables?
 [...]


If you spend any amount of time writing Java code, you can appreciate 
'final' fairly easily.  In Java, String is immutable, so a final String 
is like a const std::string.  On the other hand, Java provides 
StringBuilder for mutable operations on strings.  It's a little like 
std::stringstream, but not quite.

// Create a new StringBuilder and reserve a buffer of at least 48 chars
StringBuilder s = new StringBuilder(48);
s.append("Hello,");
...
s = methodReturningNewStringBuilder();
...
s.append(" world!");
// s.toString() == "Hello, world!"?  Maybe, maybe not

final StringBuilder s = new StringBuilder(48);
s.append("Hello,");
...
s = methodReturningNewStringBuilder(); // Error
...
s.append(" world!");
// s.toString() == "Hello, world!"?  Provably!

What you can't do in Java is declare a const or invariant StringBuilder. 
  While this example is a little contrived, once you start talking about 
file streams and JDBC Statements and ResultSets, knowing whether a 
variable has been rebound becomes a very big deal.  That is, just 
declaring a few things 'final' can eliminate a whole host of potential 
bugs and let you focus on the parts of the code that really matter.

Dave
Mar 21 2007