The compiler swallows opDispatch errors

[Steven Schveighoffer]

On 8/30/21 2:13 AM, bauss wrote:

> I'd argue that opDispatch shouldn't have any constraints on it.

If you mean *implicit constraints*, then yes. But not allowing 
constraints would be insanely awkward. We might be saying the same 
thing, but I'm not sure.

> It's a function that's rewritten by the compiler and so any error 
> checking should be done solely by the compiler and without any 
> attributing such as __traits(compiles)

I'm not sure how the compiler implements the check, but the effect is 
the same as adding a `__traits(compiles, <function body>)` constraint 
implicitly.

> 
> If an opDispatch is declared that cannot be compiled then arguably it 
> should stop the entire compilation as something is clearly wrong.

Determining the compilability of a declared template is complex -- 
usually you need an instantiation.

And opDispatch doesn't have to necessarily compile for all possible 
instantiations. For instance, opDispatch won't be used if there is 
already a member of that name.

I *think* the point of using non-compilation as an implicit constraint 
is so you can do things like:

```d
auto opDispatch(string n, Args...)(Args args) { return 
mixin("something.", n, "(args)"); }
```

and not have to repeat the callability of that in the constraint. 
However, the cure is worse than the disease here IMO.

For sure, if this were to be "fixed", we'd have to deprecate for a while 
as I'm sure some libraries utilize this "feature".

As a mitigating feature, perhaps something like `__traits(compiles, 
template)` could be added as a constraint possibility which will mean 
"the thing I'm constraining here compiles as instantiated".

-Steve