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_at_[hidden]> Gesendet:So 04.01.2026 15:13 Betreff:Re: [std-proposals] Labelled parameters An:std-proposals_at_[hidden]; CC:Barry Revzin <barry.revzin_at_[hidden]>;  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.