Parameter names are optional in function declarations. (And can be named differently from their counterpart in definitions.)

So far they were either

 - kept the same between declaration and definition -> leak of internal (implementation) data

 - used as reminder for the programmer or for popups and autocompletes in IDEs; possibly also for compile error messages

So the programmer already has a lot of flexibility. Nevertheless you are right, that the parameter names of included functions never leaked into the caller code up till now.

-----Ursprüngliche Nachricht-----
Von: Barry Revzin via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: So 04.01.2026 15:13
Betreff: Re: [std-proposals] Labelled parameters
An: std-proposals@lists.isocpp.org;
CC: Barry Revzin <barry.revzin@gmail.com>;

 

Even when the parameter names are normal-ish, that's probably not something that library authors want users to rely on. For instance, in range-v3, the predicates and projections are pretty consistently named pred and proj, but is that the correct user-facing name? Eric and Casey have never had to think about this before. max(r, .proj=key) is definitely nicer to read than max(r, {}, key), but not as nice as max(r, .key=key) (or ".by" or something else). Lack of explicit opt-in cements a decision that up until now was never even a known decision.