On 1/16/23 3:10 AM, Arjan wrote:
> On Monday, 16 January 2023 at 04:30:25 UTC, Steven Schveighoffer wrote:
>> https://www.schveiguy.com/blog/2023/01/the-cost-of-compile-time-in-d/
>>
>> Let me know what you think.
> 
> I think it is marveleous. Wondering are there any down sides to using typeof?

In this instance, no. This was just a case of "oh, look, there's ReturnType, so I can just use that" instead of trying to actively avoid using the tools in std.traits.

But in general, we still want to be able to use the cool tools that Phobos gives us without too much penalty, so the larger problem still remains -- templates just should be better performing.

In general, Phobos templates should try to avoid using simple wrappers for internal things. One thing I didn't discuss in the post is that the `ReturnType` instances here are only ever going to be instantiated *once*, and on something that is *never used* (the lambda function). Once the boolean for `isInputRange` is decided, there is no reason to keep that stuff around. Some way to cull those templates from the cache would be most welcome.

-Steve

On Sun, Jan 15, 2023 at 11:30:25PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> https://www.schveiguy.com/blog/2023/01/the-cost-of-compile-time-in-d/
[...]

Honestly, I find templates like ReturnType in std.traits a bit of a code smell. Same thing as Parameters, and a whole bunch of others.  Yes, it has a pretty-sounding name, and yes, you get to avoid writing that squint-inducing __traits(...) syntax, but if you take a step back, it just begs the question, why can't we do this directly in the language itself?

You pointed out that there are various reasons for it -- no easy way of getting an instance of the type, need to handle different kinds of callables, etc., but to me, those are all merely circumstantial issues. It begs the question, why *isn't* there a construct to obtain an instance of some type T (even if hypothetical, for the purposes of introspection)?  After all, the compiler knows T inside-out, and ought to be able to cook up a (virtual) instance of it.

The crux of the problem is that the in spite of D's metaprogramming prowess being often promoted, the language *itself* doesn't let you do certain common things easily.  It lets you use, e.g., typeof() in certain cases, but in other cases you need this or that workaround or paraphrasis, and so another std.traits wrapper template is born.  If the language had instead been extended so that you could, for example, extract the return type of some given callable directly, say typeof(return(myfunc)), then none of this would have been necessary in the first place.

Having wrappers in Phobos for doing certain things makes sense when a particular feature or introspective capability is still new / newly discovered: it wasn't anticipated so the language doesn't have a construct to express it directly, so a Phobos template helps to wrap it up in a nicer, more friendly and usable form for end users to use.  But once a particular construct has become recurrent and a standard part of D idiom, it deserves to be baked into the language directly. Especially when doing so eliminates a lot of the collateral costs.


T

-- 
What's an anagram of "BANACH-TARSKI"?  BANACH-TARSKI BANACH-TARSKI.

On 1/17/2023 1:58 PM, H. S. Teoh wrote:
> If the
> language had instead been extended so that you could, for example,
> extract the return type of some given callable directly, say
> typeof(return(myfunc)), then none of this would have been necessary in
> the first place.

https://dlang.org/spec/expression.html#is_expression

    int func();

    static if (is(typeof(func) R == return))
        pragma(msg, R);

prints:

    int

The implementation of std.traits.ReturnType is:

    template ReturnType(alias func)
    if (isCallable!func)
    {
        static if (is(FunctionTypeOf!func R == return))
            alias ReturnType = R;
        else
            static assert(0, "argument has no return type");
    }

ReturnType can do a little more than the raw IsExpression, as it can identify:

    struct G
    {
        int opCall (int i) { return 1;}
    }

On 1/18/23 5:20 PM, Walter Bright wrote:
> On 1/17/2023 1:58 PM, H. S. Teoh wrote:
>> If the
>> language had instead been extended so that you could, for example,
>> extract the return type of some given callable directly, say
>> typeof(return(myfunc)), then none of this would have been necessary in
>> the first place.
> 
> https://dlang.org/spec/expression.html#is_expression
> 
>      int func();
> 
>      static if (is(typeof(func) R == return))
>          pragma(msg, R);
> 
> prints:
> 
>      int
> 
> The implementation of std.traits.ReturnType is:
> 
>      template ReturnType(alias func)
>      if (isCallable!func)
>      {
>          static if (is(FunctionTypeOf!func R == return))
>              alias ReturnType = R;
>          else
>              static assert(0, "argument has no return type");
>      }
> 
> ReturnType can do a little more than the raw IsExpression, as it can identify:
> 
>      struct G
>      {
>          int opCall (int i) { return 1;}
>      }
> 

I didn't think of making ReturnType simplified (we know in this case the thing is not anything except a normal lambda function). I did this now:

```d
template RT(alias sym) {
    static if(is(typeof(sym) R == return))
        alias RT = R;
    else
        static assert(false, "bad");
}

...

else version(useIsExpr)
{
    enum isInputRange(R) = is(typeof(R.init) == R)
    && is(RT!((R r) => r.empty) == bool)
    && (is(typeof((return ref R r) => r.front)) || is(typeof(ref (return ref R r) => r.front)))
    && !is(RT!((R r) => r.front) == void)
    && is(typeof((R r) => r.popFront));
}
```

The result is still not as good as just using typeof directly, but much much better. When compared to a direct typeof, it adds about 0.15s of total compile time for 10000 instances, and adds 100MB more memory usage.

My point still stands -- *inside* a constraint template, you should avoid using all kinds of convenience templates if you can help it. Nobody cares about the implementation of `isInputRange`, as long as it gives the right answer.

Now, Adam has a point (in his comment on my blog) that if you are *already* using such convenience templates elsewhere on the *same parameters*, then this can have a negative effect on overall performance, because the caching of the template answer can speed up the compilation. In this case, the template instantiation is guaranteed to be unique since these are lambda expressions, so that doesn't apply.

I think we can all agree though that it is less than ideal to have to worry about the internal details of how templates are implemented.

-Steve