If the intent of such a statement is to end further discussion, I suggest actually saying that. “This is something we expect macros to eventually support and we do not intend to entertain further discussion on this point. You’ll need to do without in the mean time” would be less problematic, or at least far less ambiguous.
As it is, “have you tried a macro for this?” implies a lack of due diligence by the person asking for the feature, which isn’t really fair given the lack of a realistic path to acquiring the necessary knowledge to use them. Not everyone can sink the required days or weeks into getting familiar enough with the compiler internals to get to the point where they can forgo the need for public documentation.
No, it’s really not. It means that someone with intimate knowledge of the macro implementation thinks the problem might be solvable via macros, not that it’s actually solvable by someone without that knowledge.
Even seeing if a particular problem is actually solvable using macros requires waiting for the documentation to be fleshed out enough for someone outside the compiler group to have a go at it. In the cases where it’s not at all clear macros are a viable solution (at least with the understanding publicly available), as is the case with Curried Varargs, it becomes a situation where there’s a decent chance that we’ll need to wait until macros are documented enough to have a go at implementing it, then wait again for it to potentially be officially included in the language.
This is why I’d like to suggest that, should someone be interested in using macros to give the brush-off for a feature, they put their money where their mouth is and at least try to implement a POC and provide it as an example. If nothing else, dogfooding the macros this way will result in a better implementation.
Edit: fixed a wrong “there”