Any word on the return-type const syntax?

Stewart Gordon smjg_1998 at yahoo.com
Sat Dec 8 18:16:50 PST 2007


"Janice Caron" <caron800 at googlemail.com> wrote in message
news:mailman.263.1197106829.2338.digitalmars-d at puremagic.com...
> On 12/8/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>> Janice Caron wrote:
>>> Here's a typical problem.
>>>
>>>     class MyArray(T)
>>>     {
>>>         T[] a;
>>>
>>>         T* ptr() { return a.ptr; }
>>>         const(T)* ptr() const { return a.ptr; }
>>>         invariant(T)* ptr() invariant { return a.ptr; }
>>>     }

This doesn't work for me.  Add any one (or more) of

MyArray!(int) a;
const(MyArray!(int)) c;
invariant(MyArray!(int)) i;

and I get (DMD 2.008)

transfer_const.d(7): Error: cannot implicitly convert expression 
(cast(int*)(this.a)) of type int* to invariant(int)*

>> > A template helps how, exactly?
>>
>>         TransferConst!(U,T) ptr(this U)() { return a.ptr; }
>
> There are several things I don't understand about this example. You
> seem to be suggesting that
>
>    TransferConst!(U,T)

It doesn't seem to exist, according to a search through the DMD and Phobos 
code.

<snip>
> The next thing I don't understand is the notation
>
>    ptr(this U)()

http://www.digitalmars.com/d/template.html#TemplateThisParameter

However, it crashes DMD when I try to use it in a class member function.
Need to investigate....

> How does that even parse? I'm not familiar with this means of
> specifying template parameters. What does it mean?
>
> The third thing I don't understand is, I see no specication of the
> constancy of the member function itself. I expect to see either
> const-at-the-end, or const-at-the-start, but I see neither. Where is
> it?

In the aforementioned (this U), I think.

<snip>
>    K(this) K(T)* ptr() { return a.ptr }
>
> I think my way looks most readable, but you tell me. I don't actually
> care what the replacement symbol is. Obviously, "K" is an unwise
> choice, but you could use any reserved word (I believe "return" was
> suggested in your document), or even some combination of reserved
> words like "const in" and "const out", or whatever. (And I'd also like
> the symbol to be available within the body of the function).

"return" doesn't seem to make any sense.  I think constness template 
parameters (defined as a special case that generates only one instantiation) 
would be a good way to go - this would also make it possible to parameterize 
something on the constness of more than one entity.  How about

    K(T)* ptr(constness K : this)() { return a.ptr }

> One really important point to consider is that you need EXACTLY ONE
> instantiation of the function. That is, the bytes of machine code
> which comprise the function would be identical in all three cases, and
> therefore need to exist only once. I suspect that your template idea,
> in addition to robbing me of virtuality, would also instantiate the
> function three times.

I've a vague recollection of reading somewhere that templates that differ 
only in constness are already defined to reduce to a single instance, but I 
can't seem to find it at the moment.

But really, because of the possibility of bits of code being conditional on 
constness, we need to have both options available somehow.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit. 




More information about the Digitalmars-d mailing list