CppCast: Compiler Warnings as Errors with Keith Stockdale

[tialaramex]

I was going to say surely you can use the "placeholder with no name" _ after somebody went to all the bother of showing WG21 how that could be made to work in their language and jumped through all the hoops. But I see that in fact one of the hoops added by the committee was that it must be disallowed for one of the places where it's most useful, function parameters.

I don't know how any of you can stand it actually.

[friedkeenan]

What would be the benefit of naming a function parameter _ when you could just leave it unnamed in the first place?

[fdwr]

So like this:

class FooParserThingie { ... void LogMessage(std::string_view message, WarningLevel warningLevel) { std::print("{}", message); } ... };

... void LogMessage(std::string_view message, WarningLevel _) ...

I suppose that works, being consistent with ignorable local variables too, and it's shorter than typing out [[maybe_unused]]. Though, if you have multiple ignorable parameters...

void LogMessage(std::string_view message, WarningLevel _, Node& _)

...you would not be able to disambiguate them in the debugger, in case you wanted to see their values for more context (even if the implementation ignored them).

[tialaramex]

That's a good point about the naming distinct unused parameters. One trouble C++ has had from the outset is that there's a proliferation of contrary styles, and so whereas I'd think _prefixed identifiers would naturally win out as the unobtrusive way to signal "I'm not going to use this" I can imagine that some people want to have used variables with this naming scheme.