Is "global" the right terminology in a language that uses modules? After all, the function isn't global in the same sense that it's global in C/C++ since the function has an (implicit) enclosing module.

You're right. Another name for non-methods could be "free" functions instead of "global". But f.hasFreeName(...) sounds awkward, so another way to phrase it could be f.(FreeFunctionDecl).hasName(...)

f.hasFreeName(...) sounds awkward, so another way to phrase it could be f.(FreeFunctionDecl).hasName(...)

I'm happy with either. @MathiasVP which do you prefer?

I'm happy with either. @MathiasVP which do you prefer?

I think I like f.(FreeFunctionDecl).hasName(...) more. We should really have such a function anyway so if it also makes the ergonomics easier in this case I think it's a strong argument for choosing this one 👍.

Updated. And fixed the merge conflict. And I've added a bit more qldoc, though I'm not expecting to win any awards for:

/**
 * A function.
 */

("A function" is actually not saying nothing in this case; it's saying "Yeah, don't worry about that funky name AbstractFunctionDecl, this really is the class you want to represent a function")

("A function" is actually not saying nothing in this case; it's saying "Yeah, don't worry about that funky name AbstractFunctionDecl, this really is the class you want to represent a function")

Good point. That name should be changed eventually as well, though.