On Sunday, 16 May 2021 at 12:54:19 UTC, Chris Piker wrote:

If all you need is a single type for the parameter(s) and return type, then it can be simplified a bit to save you some typing:

struct S(T)
{
   alias FT = T function(T);
   FT func;
}

void main()
{
    auto a = S!int(a => a*2);
    auto b = S!int(a => a+2);
    a = b;
}

On Sunday, 16 May 2021 at 20:32:08 UTC, SealabJaster wrote:

You could even make a helper function that lets the compiler infer the lambda's type for you:

struct S(T)
{
   alias FT = T function(T);
   FT func;
}

S!T s(T)(T function(T) func)
{
    return S!T(func);
}

void main()
{
    auto a = S!int(a => a*2);
    auto b = s((int a) => a+2);
    a = b;
}

But that can give you awful looking error messages if you forget to add the param typing.

On Sunday, 16 May 2021 at 13:35:02 UTC, Adam D. Ruppe wrote:

Sorry, it's a forum post, so I really should have been more explicit.

It seems there's a broken symmetry in compiler error reporting for the following, ostensibly identical, cases:

struct S(alias 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();

   a = b; // Error message is understandable

   auto c = S!((int a) => a*2)();
   auto d = S!((int a) => a*2)();

   c = d; // Error message says a thing != to a same thing
}

Error messages formatted below for readability:

test.d(12): Error: cannot implicitly convert expression b of type
   S!(func2)
to
   S!(func1)

test.d(17): Error: cannot implicitly convert expression d of type
   test.S!(function (int a) pure nothrow @nogc @safe => a * 2)
to
   test.S!(function (int a) pure nothrow @nogc @safe => a * 2)

As new D programmer, this really threw me off the debugging trail. For the second case, had the compiler reported some in the order of:

test.d(17): Error: cannot implicitly convert expression d of type
   test.S!(__lambda_temp_main_1)
to
   test.S!(__lambda_temp_main_2)
Hint: All lambda function instances have unique auto-generated names

It would have saved a lot of head scratching.

Oh well, I learned quite a bit from this exchange so that's productive. Thanks all

On Sunday, 16 May 2021 at 22:17:16 UTC, Chris Piker wrote:

Oh yes, I completely agree with you.

Sometimes error messages even use the name but it is from a different module so it is like

"cannot assign Color to Color"

but one of them is from arsd.color and one is from std.experimental.color... it just wouldn't tell you that. (I think this has been fixed btw)

so yeah same thing here, it should at least check if str1 == str2, show more info.

On Sunday, 16 May 2021 at 23:52:06 UTC, Adam D. Ruppe wrote:

I've opened a PR (https://github.com/dlang/dmd/pull/12526) with a super hacked together proof-of-concept.

As I say in the PR I don't know if I'm actually capable of pushing it forward if the idea gets accepted, but I've decided to at least try to see if this kind of thing is even palatable to the compiler devs.

On Monday, 17 May 2021 at 00:27:01 UTC, SealabJaster wrote:

oh very good! I was going to add something similar to my own todo list but who knows when I'd get around to it.

This kind of thing would be a big help.

On Monday, 17 May 2021 at 00:27:01 UTC, SealabJaster wrote:

Wow! That's good news. Thanks!

Here's hoping that future versions of dmd do a bit more whitespace formatting of error messages. The current undifferentiated text walls are an early low quality user experience that can drive people away before they are invested in the language.

A final note on the initial problem that started this thread:
My overall my program works now. (None too soon, management meeting is tomorrow) To solve my previous Type Hell(tm) problems I've found that std.range.interfaces is my new best friend.

On Saturday, 15 May 2021 at 11:51:11 UTC, Adam D. Ruppe wrote:

+1