Solving a constraint hiding an error in a function literal

[Paul Backus]

On Friday, 3 February 2023 at 20:20:48 UTC, Steven Schveighoffer 
wrote:
> The problem with this is that your constraint then has to 
> become:
>
> ```d
> foo(alias bar) if (__traits(compiles, 
> exprUsingBar).hasOnlyImplementationIssues)
> ```
> That `hasOnlyImplementationIssues` is going to be messy, 
> difficult to implement, and basically redoing all that the 
> compiler is already doing. Plus, if it's just a string, it 
> might have to change with compiler versions. Essentially, 
> changing error messages becomes a breaking change.

Well, it has to become this if you specifically want the 
*semantics* of `__traits(callable)`. If you just want to do a 
better job of surfacing error messages, which is what the 
original post focused on, this is unnecessary.

Either way, even if the semantics of `__traits(callable)` are 
desirable on their own merits, I think it is worth improving 
`__traits(compiles)`, because (1) it is widely used in existing 
code, and (2) sometimes `__traits(compiles)` is actually what you 
want.