• Bruce Adams (7/7) Dec 08 2007 A 'manifest' constant is one that is never allowed to use any storage. ...
• Robert Fraser (5/15) Dec 08 2007 I don't think that's any better than "enum". And if it's used to infer
• Bruce Adams (16/28) Dec 08 2007 e. =
• Robert Fraser (9/24) Dec 09 2007 I don't care about the dictionary definition, I'm concerned that enum
• Bruce Adams (37/59) Dec 09 2007 o =

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

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.

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


e.  =

 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=


or.
 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 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 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";

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.

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


o  =

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


ot  =

 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.

  I don't see why. It could be changed to be a shorthand for:
  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=

c  =

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

ow  =

 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;