If you could make any changes to D, what would they look like?

[Paul Backus]

On Monday, 25 October 2021 at 17:45:22 UTC, H. S. Teoh wrote:
> I suspect part of this problem is caused by the lame 
> specialcased behaviour of template instantiation errors being 
> ignored when it's opDispatch.  It's D's version of C++'s 
> SFINAE, which leads to all sorts of stupidity like a typo 
> inside opDispatch suddenly causing a dispatched member to 
> disappear from existence 'cos the compiler swallows the error 
> and pretends the member simply doesn't exist.  So if you're 
> introspecting the member, the introspection code doesn't even 
> see it. Which leads to hours of head-scratching over "I 
> obviously declared the darned member, why does the code NOT see 
> it?!?!".
>
> Errors in opDispatch seriously ought to be treated as errors. 
> If some member isn't supposed to be part of the dispatch, it 
> should be checked for in the sig constraint or something like 
> that, instead of the compiler silently swallowing the error.

It's actually worse than that. Errors inside `opDispatch` are 
gagged and cause member lookup to fail...*unless* they're nested 
inside *another* template, in which case member lookup will 
succeed, and you will only get the error when you try to actually 
access the member:

```d
struct S1
{
     template opDispatch(string member)
     {
         // error is gagged by compiler
         static assert(0);
     }
}

// member lookup fails
static assert(__traits(hasMember, S1, "foobar") == false);

struct S2
{
     template opDispatch(string member)
     {
         // inner template
         auto opDispatch()()
         {
             // error is not gagged
             static assert(0);
         }
     }
}

// member lookup succeeds
static assert(__traits(hasMember, S2, "foobar") == true);
// ...but usage triggers the error
auto _ = S2.init.foobar;
```

It's special cases inside of special cases--a complete mess.