关于扩展C++以复用函数类型定义函数的提案及弊端问询

相关提案现状 #

目前C标准仅允许用typedef或using定义的函数类型进行函数声明，无法直接用于函数定义（比如你示例中的F f{ return 42; }在当前标准下是非法的）。截至目前，尚未有正式进入标准化流程的提案支持这种语法，但WG21（C标准委员会）的邮件列表中曾出现过相关讨论，不过这类提议还未形成成熟的正式提案。

支持该语法扩展的潜在弊端 #

• 语法歧义风险：函数类型的语法容易和现有特性冲突。比如当你用using F = int(int);定义函数类型后，写F f { ... }时，编译器需要区分这是函数定义，还是试图用函数类型初始化某个变量（虽然当前函数类型无法直接实例化，但扩展后可能和lambda、函数对象的语法产生混淆），这会大幅增加编译器解析的复杂度，甚至引发语法歧义。
• 参数名缺失的实用性问题：示例是无参数的简单场景，但如果函数类型包含参数类型（比如using F = int(int, double);），用这种方式定义函数时无法指定参数名，导致函数体内无法引用参数。如果要解决这个问题，要么修改函数类型的定义语法使其支持参数名（这会打破现有typedef/using的规则），要么只能放弃在函数体内使用参数，显然这两种方案都不实用。
• 破坏现有语法一致性：当前C++的函数声明和定义有明确的语法区分：声明可以复用函数类型，但定义必须显式写出参数列表（带类型、可选参数名）。这种扩展会打破这种一致性，增加语言的学习成本，开发者需要额外记住两种不同的函数定义方式，容易引发混淆。
• 模板与重载的复杂度飙升：在模板场景中，如果允许用函数类型定义函数，实例化后的函数处理逻辑会变得异常复杂；重载决议时，这类函数和普通定义的函数如何匹配也会产生大量边缘情况，给标准制定和编译器实现都带来极大挑战。
• ABI兼容性隐患：C对跨编译器的ABI兼容性要求很高，这种语法扩展可能导致不同编译器对函数定义的解析和代码生成逻辑出现差异，进而引发跨编译环境的兼容性问题，这是C标准制定中需要极力避免的。

内容的提问来源于stack exchange，提问作者user20575107