Const on the call site?

[Regan Heath]

Robert Fraser wrote:
> Well, between episodes of Veronica Mars, I thought I'd visit Digital
> Mars with an idea that just popped into my head. I understand Walter
> has solved the const thing, and the conversation has been done to
> death, so this isn't a serious proposal as it is more a mental
> language-design exercise (it wouldn't work for D anyway, since
> there's no way to use this info for functional programming or
> optimization, which are the goals of the new const regime).
> 
> 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.
> 
> Thoughts?

So the contract would be from caller to callee and would read "you can 
have this data if you promise not to modify it" as opposed to callee to 
caller "I promise not to modify this data".

Interesting... however I don't think I like it.

Say you have a piece of data which should not be modified, no matter 
what functions it's passed to, etc.  A typical const system supports 
this idea, i.e. you would say:

const Foo foo;

No matter what you did with it, where you passed it, the compiler would 
hopefully catch you trying to modify it and complain.

This new idea doesn't support that concept in as robust a manner, eg.

Foo foo;

bar(const foo);
baz(foo);  //oops forgot to put const here.

There are more "points of failure", places where you could forget to 
enforce it.

Regan