D's treatment of values versus side-effect free nullary functions

[Jonathan M Davis]

On Tuesday, July 20, 2010 06:36:57 Justin Johansson wrote:
> Perhaps this is a philosophical question, like what is time, though it
> is also a novice programmer question as well.  The question exactly
> being:
> 
> "What is the difference between a (constant/immutable) value and the
> result of calling a side-effect free function that returns the same?"
> 
> May I please petition respondents not to answer in terms of PL syntax.
> That is, this question is not about optional parentheses which some
> PL's use to make values and nullary function calls look syntactical
> alike.
> 
> Going beyond syntax and into semantics, does the D language have
> any special "opinion" or idiom relating to constant/immutable
> values versus nullary function calls?
> 
>  From my observation, the Scala PL community has had similar questions
> poised in the past (about the difference between val's and nullary
> functions) and their answer has largely given into constraints
> imposed upon Scala's implementation and semantics as are
> implementable on the Java Virtual Machine (JWM).
> 
> Thanks for answers,
> Justin Johansson

1. A const variable is a chunk of memory which can be read as a particular type 
but not written to in that context. Optimizations may remove it in some cases.

2. An immutable variable is a chunk of memory which can be read as a particular 
type and cannot be written to in any context. Optimizations may remove it in 
some cases (and likely more cases than with const).

3. A manifest constant using an enum is a value of a particular type which is 
reused throughout the code without being an addressable chunk of memory (though 
it may still actually have an address depending on what the compiler does - you 
just can't address it yourself). The value never changes and cannot be changed.

4. A pure function which takes no parameters and simply returns a value of a 
particular type is not a chunk of memory. It's a procedure at a certain location 
in memory, which is therefore addressable for the purposes of calling it (or 
passing it around to be called). When it is run, it produces a value, and it 
will always produce the same value regardless of when it is run. Optimizations 
may remove the call in some cases and simply re-use the result. Also, the 
function could be used in CTFE to produce the value at compile time and just use 
that value instead of calling the function at runtime. Depending on how the 
function is used and how much optimizing the compiler does, the function may 
never get called at runtime. But it is ultimately a function rather than a 
variable, which means that it is used as a function, including what that means 
for addressing it. So, there _will_ be cases where it cannot be optimized out 
(like if you're passing around a pointer to it and calling it through the 
pointer). It is _not_ a variable. It may get optimized to the point that it's as 
efficient as a variable, but then again, it might not be. And there are cases 
where it acts very much like the function that it is.

- Jonathan M Davis