当前实现的缺点：
- 它们违反了DRY原则，因为您必须在任何需要的地方重写参数
- 它们破坏了隐藏的实现，因为您必须指定那些已经在接口中的参数——即使只有一个接口实现需要它们
- 它们破坏了你的界面，用户可以在自动完成、文档等页面中看到它们
为什么语言设计者决定不使用更有用的东西，比如：
public void Foo()
{
Console.WriteLine(CallerInformation.File);
}
我想这个实现缺少一些功能：例如，如果Foo（）是一个实现IFoo的类，而IFoo在另一个程序集中，那么IFoo的任何调用方在编译时都应该如何知道需要这些信息——他不知道。
但是！记录这只在一个"构建步骤"内工作，而不是产生当前实现中无法使用的东西，这不是更好吗？
Q1:是否有关于为什么以现在的方式实现它的官方文档？
Q2:有人知道其他语言的更好的解决方案吗？
调用方信息属性在语义上与方法参数相关（例如"如果没有为此字符串参数指定值，则将调用方成员名称放在其中，而不是使用null作为默认值"），因此我认为没有理由不在语法上与当前的情况相关。
它们违反了DRY原则，因为你必须在任何需要它们的地方重写参数
其他方法也需要在每次想要将调用方成员名称分配给变量时执行操作，例如：param=param？？SomeExpressionToGetSomeValue
它们破坏了隐藏的实现，因为你必须指定那些已经在接口中的参数——即使只有一个接口实现需要它们
关于实现隐藏：调用者有责任提供参数，所以这应该在接口中（除非运行时决定在所有调用中始终提供这样的信息，这就像隐式提供参数一样——在幕后隐式/神奇地提供参数对我来说似乎不是更好的方法）
关于必须指定以指定接口中已经存在的参数（即使只有一个接口实现需要这些参数）：仅在需要时指定属性和参数。这就是为什么Math.Abs被声明为公共静态int Abs（int值）而不是公共静态int Abs（int值，object ThisIsNotNeedButLetsJustHaveItHereItAnyways）
它们污染了你的界面，用户可以在自动完成、文档等页面中看到它们。
嗯，我不明白你为什么认为这是一件坏事——如果调用者应该提供它的名字，它应该在文档等中。
你似乎建议自己阅读堆栈帧，这将编译和运行，但可能不会达到你的预期：
private void SomeMethod()
{
return new StackFrame(1).GetMethod().Name;
}
上面的代码将在运行时获得调用程序的名称，但由于内联或尾部调用优化，它可能与编译时 因此，如果方法在编译时（而不是运行时）需要调用方信息，那么这种方法就不起作用。