Cannot overload on constness of a struct

Janice Caron caron800 at googlemail.com
Wed Nov 7 09:35:08 PST 2007


On 11/7/07, Janice Caron <caron800 at googlemail.com> wrote:
> struct A(uint N)
> {
>     private ubyte[N] data;
>
>     ubyte * ptr() { return &data[0]; }
>     const const(ubyte) * ptr() { return &data[0]; }
> }
>
> Error: function ptr conflicts with function ptr
>
>
> If A is mutable, then ptr should return a pointer to ubyte.
> If A is const, then ptr should return a pointer to const ubyte.
>
> Please tell me this will work after the revamp of const?

If I recall correctly, there is talk of making the constness of a
return value dependent on the constness of a function parameter.

That's good - except in this particular case, the function parameter
from which the constness of the return type depends, is, in fact,
"this". Since the "this" parameter is hidden, I'm not sure if the
syntax suggested in the Walter/Andrei document will cover it.

I do kinda like the alternative template-like syntax proposal, where a
symbol like C could stand for either "const", "invariant", or nothing
at all. Then I could say

    C C(ubyte) * ptr(???? C)() { return &data[0]; }

but there are several problems even here. First off, do we need a new
keyword where I've written "????" to indicate that C is a "const-like"
symbol, not a type? Secondly, template member functions aren't allowed
anyway, so this would have be a sort of special case (which I guess is
OK, given that C has only three possible values).

More interestingly, the *exact same function* could be called in all
three cases - at least, for this example. So we're not really looking
at building three versions of the same function, merely making ONE
function, but one in which the constness of the return type is
dependent on the constness of one of the inputs.

I know this idea is already being thought about - but when we get this
feature, /please/ make sure that "this" can be one of the inputs from
which constness can be taken.



More information about the Digitalmars-d mailing list