www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another foolish idea for manifest constants

reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
A 'manifest' constant is one that is never allowed to use any storage.  =

There is
one 'type' for which this is already true - void.
So how about:

void int x =3D 3;

This is a non-breaking change as using void this way is a syntax error.
Granted void is not a storage class.
Dec 08 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bruce Adams wrote:
 
 A 'manifest' constant is one that is never allowed to use any storage. 
 There is
 one 'type' for which this is already true - void.
 So how about:
 
 void int x = 3;
 
 This is a non-breaking change as using void this way is a syntax error.
 Granted void is not a storage class.

I don't think that's any better than "enum". And if it's used to infer type as in: void str = "hello"; ... it becomes a semantic error.
Dec 08 2007
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sun, 09 Dec 2007 00:03:01 -0000, Robert Fraser  =

<fraserofthenight gmail.com> wrote:

 Bruce Adams wrote:
  A 'manifest' constant is one that is never allowed to use any storag=


 There is
 one 'type' for which this is already true - void.
 So how about:
  void int x =3D 3;
  This is a non-breaking change as using void this way is a syntax err=


 Granted void is not a storage class.

I don't think that's any better than "enum". And if it's used to infer=

 type as in:

I read void as meaning something like "nothing/none/does not exist" so i= ts = dictionary meaning fits. I am in the school that sees enums as a set (or list) of values and not = a = hack to declare constants.
 void str =3D "hello";

 ... it becomes a semantic error.

I don't see why. It could be changed to be a shorthand for: void auto str =3D "hello";
Dec 08 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bruce Adams wrote:
 I didn't say it was better just an alternative that hadn't be raised.
 I read void as meaning something like "nothing/none/does not exist" so 
 its dictionary
 meaning fits.
 I am in the school that sees enums as a set (or list) of values and not 
 a hack to
 declare constants.

I don't care about the dictionary definition, I'm concerned that enum for manifest constants is syntactically different than other modifiers in that it can't be used in blocks. This is unexpected behavior. The word "enum[erate]" fits about as well as void, final, alias, etc., IMO.
 
 void str = "hello";

 ... it becomes a semantic error.

I don't see why. It could be changed to be a shorthand for: void auto str = "hello";

This is inconsistent. "void" is a type, not a storage class, so 'void str = "hello"', the void will be parsed as a type, which the semantic pass will have to rewrite as type inference. Other storage classes allow type inference without any type being given.
Dec 09 2007
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sun, 09 Dec 2007 08:38:40 -0000, Robert Fraser  =

<fraserofthenight gmail.com> wrote:

 Bruce Adams wrote:
 I didn't say it was better just an alternative that hadn't be raised.=


 I read void as meaning something like "nothing/none/does not exist" s=


 its dictionary
 meaning fits.
 I am in the school that sees enums as a set (or list) of values and n=


 a hack to
 declare constants.

I don't care about the dictionary definition, I'm concerned that enum =

 for manifest constants is syntactically different than other modifiers=

 in that it can't be used in blocks. This is unexpected behavior. The  =

 word "enum[erate]" fits about as well as void, final, alias, etc., IMO=

 void str =3D "hello";

 ... it becomes a semantic error.

void auto str =3D "hello";

This is inconsistent. "void" is a type, not a storage class, so 'void =

 str =3D "hello"', the void will be parsed as a type, which the semanti=

 pass will have to rewrite as type inference. Other storage classes all=

 type inference without any type being given.

void has always been somewhat uncomfortable as a type. Its more an empty= = type, null-type or an anti-type or some kind of type that isn't really a type. You can't do: void foo(void) {} void bar =3D foo; //illegal syntactically never mind semantically. because a void 'type' has no storage. On the other hand in the function declaration it looks like it means "an= = empty list of arguments". Except its not because ellipsis '...' is a list of arguments (which may = be = empty) and its type is probably something like void[] or void* because the 'object' = defining an argument is not properly exposed beyond the compiler. Granted people can get at some= = of the information with clever templates. Perhaps named parameters would change this. Anyway, I think it could be wrong to consider void as a type per se. = Sometimes a 'true' type is required and sometimes not so there is probably already a parser rule like before= = you get to the semantic pass. type:=3D <types>; type-specifier:=3D type | void;
Dec 09 2007