Another foolish idea for manifest constants

[Bruce Adams]

On Sun, 09 Dec 2007 08:38:40 -0000, Robert Fraser  
<fraserofthenight at 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" 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.

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 = 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:= <types>;
type-specifier:= type | void;