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