On Sat, 5 Jul 2025 at 21:11, Xavier Bonaventura
<xavibonaventura_at_[hidden]> wrote:
>
> Not yet, that part I'm still struggling on what does it mean if one of them is not a type.

What's baffling me is that the suggested answers in your paper are
*different*. They can end up being different
for simple binary queries too. And then we have a situation where a
query for constructibility and another query for assignability
behave in a drastically different manner. I would struggle to explain that.

> I was not so sure if
> is_*_invocable_r_type and is_*_assignable_type should also be returning false if any of the parameter is not a type.
> My mental model was that if the input has only one input type then is a clear answer. When it has more than one type then it is hard to say what the answer means.
> You hit the part that I was not so sure but I'm opened to suggestions.

I do have a suggestion: leave it be. It seems far more explicable to
be able to say
"the query returns so-and-so, but if the query is performed on a
non-type, you have a logic error somewhere in your code, and the
language
will tell you" than the alternative.

If you want a set of type property queries that just returns false
when given a non-type, you can build that on top of the standard
property queries.
But you can't build the other-way-around alternative on top of
standard queries that just return false for every question, even for
arguably nonsensical
questions.

That aspect of what is and isn't a building block settles the API
design question for me.