December 12, 2007
I just want to bump this, because I feel it's not getting the attention is deserves. I have a program which is awaiting the answer to this dilemma. To repeat the problem more succintly, the mixin template B(U:U) is being passed a template parameter of const(float), but U ends up as float (without the const). This is seriously problematic. Where did my const go? Does the (U:U) notation not work for mixins? Does the expression const(M) not work if M is an alias? What's going on? Is this a compiler bug, or is there some way I can rewrite the template B to work?

I'd appreciate some help on this. Thanks.


On Dec 11, 2007 10:54 AM, Janice Caron <caron800@googlemail.com> wrote:
> The following program won't compile (and I think it should)
>
>     void main()
>     {
>         A!(float) a;
>     }
>
>     struct A(V:V)
>     {
>         pragma(msg,"Compiling A!(" ~ V.stringof ~ ")");
>         alias typeof(V) M;
>         pragma(msg,"type of M is " ~ M.stringof);
>
>         V[] a;
>
>         template B(U:U)
>         {
>             pragma(msg,"Compiling A.B!(" ~ U.stringof ~ ")");
>             U* p() { return a.ptr; }
>             pragma(msg,"Compiled A.B!(" ~ U.stringof ~ ")");
>         }
>
>         const
>         {
>             pragma(msg,"About to compile A.B!(const(" ~ M.stringof ~ "))");
>             mixin B!(const(M));
>             pragma(msg,"Finished compiling A.B!(const(" ~ M.stringof ~ "))");
>         }
>
>         pragma(msg,"Compiled A!(" ~V.stringof ~ ")");
>     }
>
>
> During compilation, the following gets printed out:
>
>     Compiling A!(float)
>     type of M is float
>     About to compile A.B!(const(float))
>     Compiling A.B!(float)
>     Compiled A.B!(float)
>     Finished compiling A.B!(const(float))
>     Compiled A!(float)
>     test.d(17): Error: cannot implicitly convert expression
> (cast(const(float)*)(this.a)) of type const(float)* to float*
>     test.d(3): template instance test.A!(float) error instantiating
>
>
> As you can see, the pragma within the const block spits out "About to
> compile A.B!(const(float))". However, when A.B is mixed in, the pragma
> at the start of A.B prints "Compiling A.B!(float)" - NOT (as one might
> expect) "Compiling A.B!(const(float))".
>
> The constancy of "const(float)" has been lost! U is now just "float",
> instead of "const(float)".
>
> In consequence, the return type of p() is wrong, and the "cannot
> implicitly convert" error results.
>
> The REAL error, however, is that U should be "const(float)", not "float". What happened? Is this a bug, or am I doing something wrong?
>
January 05, 2008
On 12/12/07, Janice Caron <caron800@googlemail.com> wrote:
> I just want to bump this, because I feel it's not getting the attention is deserves. I have a program which is awaiting the answer to this dilemma. To repeat the problem more succintly, the mixin template B(U:U) is being passed a template parameter of const(float), but U ends up as float (without the const). This is seriously problematic. Where did my const go? Does the (U:U) notation not work for mixins? Does the expression const(M) not work if M is an alias? What's going on? Is this a compiler bug, or is there some way I can rewrite the template B to work?
>
> I'd appreciate some help on this. Thanks.

Umm... Walter, this still isn't fixed.

Not trying to be a pain or anything, but in this post:
http://lists.puremagic.com/pipermail/digitalmars-d/2007-December/029769.html
I said: "I certainly hope you will look at the thread "Constancy lost
when compiling template mixin", and respond in some way - even if only
to tell me I've made some obvious and stupid error - because the issue
raised there is one that I /do/ need solving.", and then you said, and
I quote:

"I wouldn't worry about that right now, as the const stuff is getting revised again."

OK, so I waited for the revision. Now we're at D2.009, and this bug has not gone away. Please, please, please could you respond - either to tell me I've done something stupidly wrong, or to assure me that it is indeed a bug, which you plan to fix in D2.010 (for which I am now waiting ... patiently...)

Thank you