template Test(alias N)
if (isIntegral!(typeof(N)))
{
    struct S
    {
        typeof(N) n = N;

        auto opAdd(T)(T rhs)
        {
            //Error: argument S to typeof is not an expression
            pragma(msg, typeof(T));
            //Error: variable rhs cannot be read at compile time
            return Test!(n + rhs.n);
        }
    }
    auto st = S(N);
    alias Test = st;
}

void main()
{
    auto a = Test!2;
    auto b = Test!3;
    writeln(typeof(a).stringof ~ " a = ", a, ", ",
            typeof(b).stringof ~ " b = ", b, ", ",
            typeof(a + b).stringof ~ " a + b = ");
}

I don't really understand why either of these error messages are occurring. The first is just incomprehensible, and the second seems like it should work. In this case, rhs is fully accessible at compile time in the expression (a + b), so why does the compiler complain?

On Tuesday, 7 May 2013 at 06:41:25 UTC, Meta wrote:
> template Test(alias N)
> if (isIntegral!(typeof(N)))
> {
>     struct S
>     {
>         typeof(N) n = N;
>
>         auto opAdd(T)(T rhs)
>         {
>             //Error: argument S to typeof is not an expression
>             pragma(msg, typeof(T));
>             //Error: variable rhs cannot be read at compile time
>             return Test!(n + rhs.n);
>         }
>     }
>     auto st = S(N);
>     alias Test = st;
> }
>
> void main()
> {
>     auto a = Test!2;
>     auto b = Test!3;
>     writeln(typeof(a).stringof ~ " a = ", a, ", ",
>             typeof(b).stringof ~ " b = ", b, ", ",
>             typeof(a + b).stringof ~ " a + b = ");
> }
>
> I don't really understand why either of these error messages are occurring. The first is just incomprehensible, and the second seems like it should work. In this case, rhs is fully accessible at compile time in the expression (a + b), so why does the compiler complain?

First error occures,because typeof(T) is undefined - T is a
type,not value.
About second error,although in this case rhs is
accessible,compiler can't know
that you won't call this function in runtime,so it's expected -
it's just ordinary function.

Sorry for my english.

On Tuesday, 7 May 2013 at 06:41:25 UTC, Meta wrote:
> I don't really understand why either of these error messages are occurring. The first is just incomprehensible, and the second seems like it should work. In this case, rhs is fully accessible at compile time in the expression (a + b), so why does the compiler complain?

1) typeof don't work on types. Period. It is often inconvenient in generic code (I'd love it typeof(T) to be T for simplicity) but it is how it is done now. In your case pragma(msg, T) will be correct one.

2) template parameter must be known at compile time. "rhs" is a plain function parameter, so compiler can't be sure it is known at compile time, so it is an error. Same goes for n. In general, only enum's and template parameters can be assumed to be known at compile-time. Your code seems to wrongly mix plain variables with template code all over.

If you can explain for behavior/API you are trying to achieve, most likely I'll be able to provide a more idiomatic D solution.

On 2013-05-07 08:41, Meta wrote:
> template Test(alias N)
> if (isIntegral!(typeof(N)))
> {
>      struct S
>      {
>          typeof(N) n = N;
>
>          auto opAdd(T)(T rhs)
>          {
>              //Error: argument S to typeof is not an expression
>              pragma(msg, typeof(T));
>              //Error: variable rhs cannot be read at compile time
>              return Test!(n + rhs.n);
>          }
>      }
>      auto st = S(N);
>      alias Test = st;
> }
>
> void main()
> {
>      auto a = Test!2;
>      auto b = Test!3;
>      writeln(typeof(a).stringof ~ " a = ", a, ", ",
>              typeof(b).stringof ~ " b = ", b, ", ",
>              typeof(a + b).stringof ~ " a + b = ");
> }
>
> I don't really understand why either of these error messages are
> occurring. The first is just incomprehensible, and the second seems like
> it should work. In this case, rhs is fully accessible at compile time in
> the expression (a + b), so why does the compiler complain?

As a workaround for "typeof" you can use this:

https://github.com/jacob-carlborg/orange/blob/master/orange/util/Traits.d#L213

-- 
/Jacob Carlborg

On Tuesday, 7 May 2013 at 11:03:31 UTC, Jacob Carlborg wrote:
> As a workaround for "typeof" you can use this:
>
> https://github.com/jacob-carlborg/orange/blob/master/orange/util/Traits.d#L213

You may want to update your implementation: http://dpaste.1azy.net/640a2580

On Tuesday, 7 May 2013 at 10:33:58 UTC, Dicebot wrote:
> On Tuesday, 7 May 2013 at 06:41:25 UTC, Meta wrote:
>> I don't really understand why either of these error messages are occurring. The first is just incomprehensible, and the second seems like it should work. In this case, rhs is fully accessible at compile time in the expression (a + b), so why does the compiler complain?
>
> 1) typeof don't work on types. Period. It is often inconvenient in generic code (I'd love it typeof(T) to be T for simplicity) but it is how it is done now. In your case pragma(msg, T) will be correct one.
>
> 2) template parameter must be known at compile time. "rhs" is a plain function parameter, so compiler can't be sure it is known at compile time, so it is an error. Same goes for n. In general, only enum's and template parameters can be assumed to be known at compile-time. Your code seems to wrongly mix plain variables with template code all over.
>
> If you can explain for behavior/API you are trying to achieve, most likely I'll be able to provide a more idiomatic D solution.

This is a little test to see if I can wrap types in structs and
do some checking at compile time. For example, statically
verifying in opAdd that neither number being added is negative. I
added in the pragma to see what T's type is because I had the
example compiling before, but two S structs added together was
giving a result of void, and I was trying to figure out why that
was happening.

On 2013-05-07 13:08, Dicebot wrote:

> You may want to update your implementation: http://dpaste.1azy.net/640a2580

Thanks.

-- 
/Jacob Carlborg

On Tuesday, 7 May 2013 at 15:05:40 UTC, Meta wrote:
> This is a little test to see if I can wrap types in structs and
> do some checking at compile time. For example, statically
> verifying in opAdd that neither number being added is negative. I
> added in the pragma to see what T's type is because I had the
> example compiling before, but two S structs added together was
> giving a result of void, and I was trying to figure out why that
> was happening.

To sum up short: you can't. Not because of D limitations but for unfortunate reason magic does not really work in our world. You can't check at compile-time data that is known only at run-time and function body can't possibly know anything about caller. It can be called from anywhere by anyone.

However, if you only want to allow opAdd to accept data known at compile-time, you can either move it to template argument or just make a run-time check and execute whole function with CTFE. That is most likely reason your snippet has worked for a simpler code - CTFE kicked in and everything including function body was completely evaluated at compile-time.

But no, you can't possibly check function argument at compile-time, not without extra restrictions. Better approach may be enforcing restriction into the type system by defining some NonNegativeInt user type that implements semantics you want. But even then it will need some sort of run-time check in constructor, important benefit is that it only needs to be run once upon boxing.

Make your choices and I am ready to help :)

I tried defining opAdd for S as following:

auto opAdd(alias rhs)()
if (is(typeof(rhs) == S))
{
    return Test!(n + rhs.n);
}

Which I know is kind of silly, since I can't use opAdd to do a + b anymore, but it fails to compile anyway. The compiler says that b (of type Test) does not match a's version of opAdd, which doesn't seem right to me.

Removing the template constraint doesn't help either, as I run into "local variable argument to non-global template" bug, and I can't get the structs to be evaluated at compile time, so I guess that's a lost cause.