Recommendations on avoiding range pipeline type hell
Chris Piker
chris at hoopjump.com
Sun May 16 12:54:19 UTC 2021
On Sunday, 16 May 2021 at 10:10:54 UTC, SealabJaster wrote:
> It's due to a quirk with passing lambdas as template arguments.
> Each lambda is actually separated into its own function.
Hey that was a very well laid out example.
Okay, I think the light is starting do dawn. So if I use lambdas
as real arguments (not type arguments) then I'm just storing
function pointers and I'm back to C land where I understand
what's going on. Though I may lose some safety, I gain some
sanity.
For example:
```d
alias EXPLICIT_TYPE = int function (int);
struct Tplt(FT)
{
FT f;
}
void main()
{
auto a = Tplt!(EXPLICIT_TYPE)( a => a+3);
auto b = Tplt!(EXPLICIT_TYPE)( a => a*2);
a = b; // Lambdas as arguments instead of types works
}
```
Here's the non-lambda version of your example that helped me to
understand what's going on, and how the function called get's
mashed into the type (even though `typeid` doesn't tell us that's
what happens):
```d
struct S(alias Func)
{
pragma(msg, __traits(identifier, Func));
}
int func1(int a){ return a*2; }
int func2(int a){ return a*2; }
void main()
{
auto a = S!func1();
auto b = S!func2();
pragma(msg, typeof(a));
pragma(msg, typeof(b));
a = b;
}
```
I'm going to go above my station and call this a bug in
typeof/typeid. If the function name is part of the type, that
should be stated explicitly to make the error messages more
clear. We depend on those type names in compiler messages to
understand what's going on.
Cheers,
More information about the Digitalmars-d-learn
mailing list