Ramifications of const

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Wed Jun 13 11:49:42 PDT 2007


OF wrote:

> Georg Wrede Wrote:
> 
>> Conclusion
>> 
>> For the purposes of language development, we now have two attributes for
>> each function: does it change its arguments, and does it change anything
>> else. I'd actually like to have these incorporated into the function
>> signature. A function can only be Pure if all the functions it calls are
>> Pure (i.e. do not change anything) and it is Pure itself.
>> 
>> It might be useful to have "does chanege its arguments" as a flag which
>> can quickly be checked during compilation, even if it is deducable from
>> the argument declarations. This may speed things up. But the *more*
>> important flag would be whether the function may change "external"
>> things. This is hard to see without a flag in the signature.
>> 
>> 
>> I see that pure functions will gain more importance in the near future
>> of D, and therefore we should prepare for it now with this flag.
> 
> I've actually been thinking about exactly this (pure functions in D) and
> can't let this pass without giving it support.
> 
> Pure functions are great for both bug fighting reasons and optimizations.
> Knowing that a function doesn't have any side effects at all means that it
> can not be the source of "weird" bugs, and it means that it can run
> concurrently. That it has the same return value for any given input is
> nice for optimizations -- one could even implement dynamic programming
> generation in the compiler (though I can't say I'd suggest that for D),
> and if the input is constant pure functions can always be run at compile
> time.

D has CTFE which allows execution of "pure functions" at compile time. Also
using functions as compile time generators doesn't imply they can't have
side effects. It's just a design decision.

> Those that haven't used pure functional or even just functional languages
> might not appreciate the simplifications pure functions brings, but it
> makes very much sense to use on "real" functions (like mathematical
> functions, as compared to procedures/subroutines).

I don't believe D is going to be purely functional anywhere in the near
future. There was only talk about constness of e.g. function parameters and
certain variables.



More information about the Digitalmars-d mailing list