define should be the keyword for manifest constants

[Steven Schveighoffer]

"Jason House"  wrote
> Gilles G. Wrote:
>
>> "define" makes no sense if you want to declare a "const" member function.
>> It could be of great use for manifest constant, but you'd still have to 
>> find a word for other const cases...
>
> I have absolutely no problem with different logical things using different 
> keywords.  IMHO, shoe-horning keywords to fit a new and unanticipated case 
> is not desirable.  I'd hate to see manifest constants without types.  I'd 
> probably vote against define simply because I associate it with a loss of 
> type info (probably the influence of C)

define int x = 0;

What's wrong with that?

> I'm not yet convinced in what cases manifest constants are important.  I 
> think most headers defining integral constants should be enums instead of 
> (C) #define.  That's probably one reason the enum keyword gained some 
> traction.

They are important because they occupy code space if they are not used.  For 
example, if you have 10,000 constants defined in a module, but you only need 
10 of them, then your code now has 10,000 constants in it, whereas if you 
define 10,000 manifest constants, only the ones you use are included because 
they are inlined in the code.

> If manifest constants go beyond integral types, is it better to extend 
> enums to contain more types than just integer?  Or is it better to use 
> another keyword?

enum does not capture what we are trying to do.  We are trying to make an 
instance of a certain type into a manifest constant, not define a new type.

>I kind of like the pure proposal because it does fit in with the concept of 
>pure functions.

I like pure more than enum, but the issue I have with pure is that a pure 
struct that has methods would imply only pure methods could be called.  Of 
course, having a manifest constant struct would mean there would be no 
address to pass to a member function, but people have suggested that one can 
make a copy of the struct on the stack and then call the method on that.  In 
any case, pure would be acceptable to me, but it really doesn't make any 
intuitive sense.  If you had never heard of functionali programming and pure 
functions, and you read a D file that had:

pure x = 0;

What would you think pure means?

>With the whole const vs. invariant thing, even const as a keyword doesn't 
>make a whole lot of sense (it'd really be invariant).
>
> Of course, I wonder why the compiler can't just determine which constants 
> should be manifest and which need allocation.  It could very well be that 
> we just say define manifest constants like any other constants and then 
> *if* you don't trust the compiler to get it right, use an attribute to 
> force the compiler in the right direction.

How would the compiler know when compiling a module with a constant whether 
some other module is going to take the address of that constant?  Plus it is 
nice to be able to FORCE the compiler to say "you can't use this like a 
non-manifest constant"

But I do agree that it would be nice if the compiler could optimize when 
possible.

-Steve