any news on const/invariant?

[Walter Bright]

Janice Caron wrote:
> On 11/27/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>> That's only if one thinks that const, when applied to a function, also
>> influences its return type. There is no reason why transitive const
>> should apply in this way.
> 
> I do understand. But I'm thinking of the poor programmer who hasn't
> unravelled all the knots yet, and wants a member function to return a
> const ubyte[]. Such a programmer could easily accidentally end up
> writing
> 
>     const ubyte[] f() {/*...*/}
> 
> thinking (not unreasonably) that this will return a const ubyte[] ...
> and being completely wrong.

Since a const array cannot be implicitly cast to a non-const, he'll get 
a compilation error. It's the big feature of const-correctness, the code 
won't compile if you get it wrong.


>>> Perhaps this is a case where "const at the end"
>>> creates a more helpful mneumonic?
>> It leads to awful looking code when you have a lot of them to do.
> 
> If you're making const-at-the-end syntactically valid, then it's fair
> game to use it. If you don't want it used, don't make it legal.
> 
> But if you /do/ make it legal, the (apparent) disambiguation it gives
> is, I feel, helpful.
> 
> Other possible syntaxes have been suggested. Here's another one to consider:
>     ReturnType const(functionName)(parameters...)

Sorry, but that's awful looking (besides looking confusingly like a 
template).