const debacle

[Davidson Corry]

Steven Schveighoffer wrote:
> I think that we're all arguing the same point here :)

Of course -- that's half the fun! <grin>

> All of our suggestions accomplish the same thing, but I think yours is a tad 
> less expressive than Janice's and mine.
>            [ some deleted ]
> Regarding using 'const' as the keyword for 'const during the function, but I 
> can return the same type as you gave me', I think in order to use the 
> parentheses scheme, we'd have to use another keyword.  But I think that the 
> scheme should be just as expressive as const is now, which I don't see 
> happening with the trailing const notation.

Point well taken. I think language designers -- and wannabes like me -- 
will stand on their heads to avoid adding a new keyword, both to avoid 
pilfering an identifier from the namespace, and because, when it turns 
out to have been a mistake, removing a keyword from a language is 
terribly difficult. But if standing the syntax on its head to avoid a 
new keyword turns out to restrict expressiveness and clarity, it may be 
justified to add one.

A keyword approach that occurs to me is
	asif const(T)
or perhaps expressed even better
	locally const(T)

But I dislike this because the new keyword can ONLY be used as an 
annotation to a function parameter. I can't think of a place in regular 
code where it would be useful. And it seems wrong to "waste" a keyword 
on so specialized a purpose.

You can always express the "locally const" notion in your own code by 
making a copy of a (possibly non-const) parameter reference to a local 
reference that IS const, and using that in the body of your function, 
then return a value based on the original parameter reference. And the 
compiler will catch it when you mis-use the "consticated" reference. 
What this does NOT do is to PUBLISH that "promise" to callers of your 
function so that they can rely on it and possibly optimize against it.

But it's a legitimate question to ask, is this facility useful enough to 
be worth bloating the syntax of the language? And if so, is this 
necessarily the best way to publish that information?

I noted in an earlier post that "locally const" for a parameter becomes 
in essence a part of the function's contract. Perhaps this annotation 
could be expressed, not in the function's parameter list, but in an in{} 
or out{} block instead. That would also allow it to be optimized away in 
a release build, perhaps.

In Eiffel, the contract conditions are considered as much a part of a 
method's "signature" as the parameter list -- see the short/flat views 
of a class. I don't know if the same attitude prevails in the D world. I 
know that few users of C-derived contracting languages (iContract and 
Jass for Java, Spec#, etc.) that I have spoken with really grasped the 
concept.

Likewise I don't know of any Eiffel compilers that inspect the pre- 
and/or postconditions and optimize callers against them. But I don't see 
any theoretical reason why they couldn't...

-- Dai