www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: const again

reply Paul Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Walter Bright Wrote:

 
 That leaves what to do about manifest constants. It occurs that we 
 already have a mechanism for them - enums. So why not:
 	enum x = 3;
 	enum long y = 4;
 ? I think that solves our problem.
 
 There's one last problem:
 	class C { }
 	const(C)[] a;
 	a[3] = new C();  // error, x[3] is const
 does not work with this new regime. Every twist we tried to make it work 
 caused other problems. Eventually, it just became clear that this just 
 is not going to work. But, the following does work:
 	a ~= new C();
 	a = a[1..3];
 	a = b;
 just like for strings. One can copy, concatenate, and slice such arrays 
 (just like for strings). It's not so bad. Andrei also mentioned the 
 possibility of using a template:
 	TailConst!(C)[] a;
 which would do whatever was necessary under the hood to allow the 
 elements of a to be rebound while still keeping the contents of the C 
 objects const.

I don't care for 'enum' used in this way. It distracts from (dilutes?) the meaning as an enumerated type. How about final? final x = 3; final real y = 7.5; 'final' is already a keyword and it's already used to declare one flavor of const in Java. Paul
Dec 06 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Paul Anderson wrote:
 Walter Bright Wrote:
 
 That leaves what to do about manifest constants. It occurs that we 
 already have a mechanism for them - enums. So why not:
 	enum x = 3;
 	enum long y = 4;
 ? I think that solves our problem.

 There's one last problem:
 	class C { }
 	const(C)[] a;
 	a[3] = new C();  // error, x[3] is const
 does not work with this new regime. Every twist we tried to make it work 
 caused other problems. Eventually, it just became clear that this just 
 is not going to work. But, the following does work:
 	a ~= new C();
 	a = a[1..3];
 	a = b;
 just like for strings. One can copy, concatenate, and slice such arrays 
 (just like for strings). It's not so bad. Andrei also mentioned the 
 possibility of using a template:
 	TailConst!(C)[] a;
 which would do whatever was necessary under the hood to allow the 
 elements of a to be rebound while still keeping the contents of the C 
 objects const.

I don't care for 'enum' used in this way. It distracts from (dilutes?) the meaning as an enumerated type. How about final? final x = 3; final real y = 7.5; 'final' is already a keyword and it's already used to declare one flavor of const in Java. Paul

That's not bad either. final, alias, macro -- they all make more sense than reusing 'enum' for manifest constants that aren't really enumerating anything. --bb
Dec 06 2007
next sibling parent reply sambeau <please-dont-spam-sambeau mac.com> writes:
Bill Baxter Wrote:

 Paul Anderson wrote:
 Walter Bright Wrote:
 
 That leaves what to do about manifest constants. It occurs that we 
 already have a mechanism for them - enums. So why not:
 	enum x = 3;
 	enum long y = 4;
 ? I think that solves our problem.

 There's one last problem:
 	class C { }
 	const(C)[] a;
 	a[3] = new C();  // error, x[3] is const
 does not work with this new regime. Every twist we tried to make it work 
 caused other problems. Eventually, it just became clear that this just 
 is not going to work. But, the following does work:
 	a ~= new C();
 	a = a[1..3];
 	a = b;
 just like for strings. One can copy, concatenate, and slice such arrays 
 (just like for strings). It's not so bad. Andrei also mentioned the 
 possibility of using a template:
 	TailConst!(C)[] a;
 which would do whatever was necessary under the hood to allow the 
 elements of a to be rebound while still keeping the contents of the C 
 objects const.

I don't care for 'enum' used in this way. It distracts from (dilutes?) the meaning as an enumerated type. How about final? final x = 3; final real y = 7.5; 'final' is already a keyword and it's already used to declare one flavor of const in Java. Paul

That's not bad either. final, alias, macro -- they all make more sense than reusing 'enum' for manifest constants that aren't really enumerating anything. --bb

how about replacing 'enum' with 'def' def X { A, B, C } def { A, B = 5+7, C, D = 8, E } def int A = 0; def int B = 1; def int C = 2; def x = 3; def long y = 4; Then we aren't changing the implementation, just the semantics so that they fit the implementation better. ... thoughts?
Dec 06 2007
next sibling parent guslay <guslay gmail.com> writes:
I've always thought of enum a special case of constant value. Now I guess
constants will become a special case of enum?

But seriously, I hope that in the end we will agree on the preferred way to
define a constant value (of which we are not interested in taking the address
of).

Currently there is const/invariant int, which take storage and in this specific
case are so completely redundant that I never know which one to use. There is
enum, which has all the requirement but feels odd to generalize (as suggested
if enum was spelled "let" or "def" there would be no problem using it for both
enumerations and constant values).

So whatever syntax is chosen, I hope it's the last!

gus

sambeau Wrote:

 Bill Baxter Wrote:
 
 Paul Anderson wrote:
 Walter Bright Wrote:
 
 That leaves what to do about manifest constants. It occurs that we 
 already have a mechanism for them - enums. So why not:
 	enum x = 3;
 	enum long y = 4;
 ? I think that solves our problem.

 There's one last problem:
 	class C { }
 	const(C)[] a;
 	a[3] = new C();  // error, x[3] is const
 does not work with this new regime. Every twist we tried to make it work 
 caused other problems. Eventually, it just became clear that this just 
 is not going to work. But, the following does work:
 	a ~= new C();
 	a = a[1..3];
 	a = b;
 just like for strings. One can copy, concatenate, and slice such arrays 
 (just like for strings). It's not so bad. Andrei also mentioned the 
 possibility of using a template:
 	TailConst!(C)[] a;
 which would do whatever was necessary under the hood to allow the 
 elements of a to be rebound while still keeping the contents of the C 
 objects const.

I don't care for 'enum' used in this way. It distracts from (dilutes?) the meaning as an enumerated type. How about final? final x = 3; final real y = 7.5; 'final' is already a keyword and it's already used to declare one flavor of const in Java. Paul

That's not bad either. final, alias, macro -- they all make more sense than reusing 'enum' for manifest constants that aren't really enumerating anything. --bb

how about replacing 'enum' with 'def' def X { A, B, C } def { A, B = 5+7, C, D = 8, E } def int A = 0; def int B = 1; def int C = 2; def x = 3; def long y = 4; Then we aren't changing the implementation, just the semantics so that they fit the implementation better. ... thoughts?

Dec 06 2007
prev sibling parent guslay <guslay gmail.com> writes:
Denton Cockburn Wrote:

 
 You've mentioned this already, but D's already got too many keywords.  I 
 think enum/macro is fine if it's explained in the docs.
 
 Let's not add more keywords, esp. for minimal net benefit.

Having specific, obvious keywords for different concepts may cause less confusion than selecting a loosely related keyword from the existing pool based on a best match approach. But then again I am not the one who pays for implementing it so it's easy to say.
Dec 07 2007
prev sibling next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Thu, 06 Dec 2007 21:44:09 -0500, sambeau wrote:

 Bill Baxter Wrote:
 
 Paul Anderson wrote:
 Walter Bright Wrote:
 
 That leaves what to do about manifest constants. It occurs that we
 already have a mechanism for them - enums. So why not:
 	enum x = 3;
 	enum long y = 4;
 ? I think that solves our problem.

 There's one last problem:
 	class C { }
 	const(C)[] a;
 	a[3] = new C();  // error, x[3] is const
 does not work with this new regime. Every twist we tried to make it
 work caused other problems. Eventually, it just became clear that
 this just is not going to work. But, the following does work:
 	a ~= new C();
 	a = a[1..3];
 	a = b;
 just like for strings. One can copy, concatenate, and slice such
 arrays (just like for strings). It's not so bad. Andrei also
 mentioned the possibility of using a template:
 	TailConst!(C)[] a;
 which would do whatever was necessary under the hood to allow the
 elements of a to be rebound while still keeping the contents of the
 C objects const.

I don't care for 'enum' used in this way. It distracts from (dilutes?) the meaning as an enumerated type. How about final? final x = 3; final real y = 7.5; 'final' is already a keyword and it's already used to declare one flavor of const in Java. Paul

than reusing 'enum' for manifest constants that aren't really enumerating anything. --bb

how about replacing 'enum' with 'def' def X { A, B, C } def { A, B = 5+7, C, D = 8, E } def int A = 0; def int B = 1; def int C = 2; def x = 3; def long y = 4; Then we aren't changing the implementation, just the semantics so that they fit the implementation better. ... thoughts?

You've mentioned this already, but D's already got too many keywords. I think enum/macro is fine if it's explained in the docs. Let's not add more keywords, esp. for minimal net benefit.
Dec 07 2007
prev sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Fri, 07 Dec 2007 04:14:39 -0500, guslay wrote:

 Denton Cockburn Wrote:
 
 
 You've mentioned this already, but D's already got too many keywords. 
 I think enum/macro is fine if it's explained in the docs.
 
 Let's not add more keywords, esp. for minimal net benefit.

Having specific, obvious keywords for different concepts may cause less confusion than selecting a loosely related keyword from the existing pool based on a best match approach. But then again I am not the one who pays for implementing it so it's easy to say.

From the explanations of what enum actually does in D (which is different than C/C++ already), it actually makes a lot of sense. I figure D changes to the meaning of C/C++ keywords are already documented, so it's not a big deal to just add: and it also means... Why use new keywords to express concepts that are already explainable with current and documented keywords...
Dec 07 2007