Solving a constraint hiding an error in a function literal

[FeepingCreature]

On Friday, 3 February 2023 at 12:43:54 UTC, Nick Treleaven wrote:
> When a constraint for an alias parameter checks that calling it 
> compiles, it instantiates any function literal template. That 
> triggers any latent bugs in the user's function literal that 
> couldn't be detected before IFTI instantiates it. Those bugs 
> then cause the constraint to fail, because the literal does not 
> compile. The constraint then removes the otherwise matching 
> template from the list of candidates to use.
> ```d
> void f(alias a)() if (is(typeof(a()))) {}
>
> void main()
> {
>     f!(x => blarg);
> }
> ```
> https://issues.dlang.org/show_bug.cgi?id=11907
> https://issues.dlang.org/show_bug.cgi?id=14217
> ...
> What if there was a new trait to solve this? Suppose 
> `__traits(callable, expr, args)`, that just does IFTI (if 
> `expr` is a function template) and then checks that the 
> parameter list of `expr` accepts `args`. It does not check that 
> `expr(args)` actually compiles, it ignores any errors in the 
> body of `expr`.

Fully agreed. This is one of the biggest "simple" inadequacies in 
D's lambda-based metaprogramming. See also slide 9 from my 2020 
DConf presentation http://dconf.org/2020/online/slides/mathis.odp 
"__traits(compiles) is Satan, the great Deceiver".