Const on the call site?
Georg Wrede
georg at nospam.org
Thu Nov 15 08:58:38 PST 2007
Walter Bright wrote:
> Robert Fraser wrote:
>
>> What about requiring constants be declared on the call site rather
>> than at the function declaration? The compiler then checks the
>> function and issues an error if the value isn't const. That way,
>> library writers wouldn't have to worry at all about const, so only
>> the people ho WANTED to use const in their code could. It's not part
>> of the interface of a function, but for most functions, it's the
>> caller who knows whether or not the data SHOULD be constant, and that
>> way the caller can see automatically that a function changes
>> something, and find out where.
>
>
> This comes under the heading of 'interprocedural analysis', and it
> requires that the compiler have access to all the source for all the
> functions (in fact, 100% of the source to the entire program). Such
> makes it impossible to have opaque interfaces or anything that
> recursively depends on opaque interfaces.
>
> This would include anything that calls anything that depends on the C
> runtime library (or any other C library). The compiler would have to
> understand every language used for every part of the program.
Just hypothetically, what if the name mangling already contained a bit
to signify whether the function has No Side Effects?
Thus the compiler would know, even if the library souce is absent.
I can't help thinking that this single thing would give most of the
benefits now sought with (variously elaborate) constness schemes, while
being conceptually trivial, easy to implement, and robust within its domain.
When compiling a new function, it IMHO is easy for the compiler to
notice whether this new function has any side effects. And if it does,
then show that in the mangled name.
We have essentially two design choices here: either a single tag for
Entirely Pure vs not, or a more comprehensive tagging scheme. The latter
choice comprises a separate tag for each of the arguments, and one extra
tag for Has Side Effects Outside Its Arguments. (As in changing globals
or whatever.)
(I'd assume the programmer is interested in the argument tags, while the
compiler is also interested in the side effects tag for optimizing etc.)
IMHO, the programmer should assume that a function doesn't change its
arguments unless specifically stated. Therefore a normal function call
foo(x);
should be taken as assuming x not to change. For the situation where the
programmer wants to allow x to change, he sould write
foo(var x);
Of course, we will use six months upon deciding which particular keyword
to use here instead of "var". (I wrote "var" here just arbitrarily, no
problem.)
If you use foo(x) where foo actually is a function that does
(potentially) change x, then you'd get a compiler error.
------
I'd actually love this to be in D -- and remain, even if a Fancy and
Comprehensive Solution is invented for the Const Problem one day, too.
------
If foo changes y via, say, x.addressOfY, then foo(var x) should be
written, because x is used to get at whatever is changed.
C routines called should implicitly be considered as changing any
variables that are not passed by value.
As with any other thing in D, this is not deliberate-suicide-proof, but
I think this is Adequate.
More information about the Digitalmars-d
mailing list