1 day ago

On Friday, 1 August 2025 at 10:21:53 UTC, Nick Treleaven wrote:

>

Regarding implementation, I infer that the body of the function should not be analysed for this trait. That means attributes won't be inferred, so the call actually may not compile even if the body has no error. I.e. the body may be @safe but because the function is not marked @safe, canCall has to give false when used in a @safe context. Otherwise, how would it work?

Alternatively, if function attributes should be ignored, perhaps the trait shouldn't be called 'canCall', but 'canResolve'?

22 hours ago

On Friday, 1 August 2025 at 10:21:53 UTC, Nick Treleaven wrote:

>

Regarding implementation, I infer that the body of the function should not be analysed for this trait. That means attributes won't be inferred, so the call actually may not compile even if the body has no error. I.e. the body may be @safe but because the function is not marked @safe, canCall has to give false when used in a @safe context. Otherwise, how would it work?

Correct. The point is to hook the lookup rules only. But then you should get the error "you tried to call this unsafe function from this safe function, here's the error:..." This is more desirable than compilation of wrong things.

Maybe canCall is not the greatest name. Maybe canResolve? I don't know.

The point is to avoid the situation where code has a bug in it, but is swallowed by __traits(compiles). This is incredibly frustrating, because you are looking at code that should compile so you think, but it is completely ignoring it. The toString example is very common.

Due to the nature of templates especially, things don't show up unless you use it. But basing introspection on "does this thing and everything it uses compile" is just too blunt of an instrument.

-Steve

1 2
Next ›   Last »