define should be the keyword for manifest constants

[Russell Lewis]

Derek Parnell wrote:
> On Thu, 13 Dec 2007 15:13:11 -0700, Russell Lewis wrote:
> 
>> Bill Baxter wrote:
>>> Russell Lewis wrote:
>>>> I thought about suggesting this, but what turned me off to it was this 
>>>> declaration:
>>>>
>>>>     define int x = some_compile_time_func();
>>>>
>>>> A C/C++ programmer will probably think of this as a #define-style 
>>>> substitution, which means that he will expect the function to run 
>>>> every time that he uses the constant.  However, what we are trying to 
>>>> declare is a manifest constant.  It seemed like it would introduce 
>>>> confusion.
>>> That may be their first guess as to what it does, but it doesn't seem 
>>> like it would be difficult to relieve oneself of that misconception.
>>>
>>> And in any case, the only time the above would work is if 
>>> some_compile_time_function() really is a compile time function.  So it 
>>> doesn't really matter if the user wants to think of it as evaluating 
>>> every time it's used or just once.  That's the whole point of 
>>> compile_time / pure functions.  No side effects and context doesn't matter.
>> I'm certainly not one who argues that we should take things from C/C++ 
>> without reconsidering them! :)  I am just of the opinion that if we have 
>> some other good choice for the keyword ("pure"), it is desirable not to 
>> cause confusion.
>>
>> IMHO, it's better for a C++ programmer to say "I've never seen that 
>> keyword, let me look up what it does," than to say "I know what that 
>> does" - and be wrong.  Yes, you can re-teach them.  But if the keyword 
>> is unfamiliar, then you re-teach them the *first* time that they see it, 
>> not ages later when they stumble upon a subtle bug.
> 
> Right ... like static, const, final, int, long, struct ... all used in
> C/C++ but not in quite the same way.

True.  But we can make any new features the "right" way (if you guys 
agree that my way is the "right" way, of course!)   :)