Это может упростить конструкторы, особенно для неизменяемых типов (которые важны для многопоточности) - полное обсуждение см. Здесь . Не так хорошо, как , должно быть , возможно, но лучше, чем иметь много перегрузок. Очевидно, вы не можете использовать инициализаторы объектов с неизменяемыми объектами, поэтому обычно:
new Foo {Id = 25, Name = "Fred"}
недоступно; Я согласен на:
new Foo (Id: 25, Name: "Fred")
Это может быть расширено до общей идеи упрощения перегрузок, но в большинстве случаев я бы предпочел перегрузки, которые рекламируют допустимые комбинации. IMO, конструкторы немного отличаются, поскольку вы (обычно) определяете начальное состояние.
COM-сторона вещей также важна для многих людей, но я просто не использую COM-взаимодействие - так что это не , как , важно для меня.
Редактировать повторные комментарии; почему они просто не использовали тот же синтаксис, что и атрибуты? Просто - это может быть неоднозначно с другими членами / переменными (что не является проблемой с атрибутами); возьмите пример:
[XmlElement("foo", Namespace = "bar")]
, который использует один обычный параметр (для ctor, "foo") и одно именованное присваивание. Итак, предположим, что мы используем это для обычных именованных аргументов:
SomeMethod("foo", SecondArg = "bar");
(который также может быть конструктором; для простоты я использовал метод)
Теперь ... что если у нас есть переменная или свойство с именем SecondArg? Это было бы неоднозначно между использованием SecondArg в качестве именованного аргумента для SomeMethod и назначением "bar" для SecondArg и передачей "bar" в качестве обычного аргумента .
Для иллюстрации, это допустимо в C # 3.0:
static void SomeMethod(string x, string y) { }
static void Main()
{
string SecondArg;
SomeMethod("foo", SecondArg = "bar");
}
Очевидно, что SecondArg может быть свойством, полем, переменным и т. Д ...
Альтернативный синтаксис не имеет этой неоднозначности.
<ч />
Редактировать - этот раздел на 280Z28: Извините, что добавил это сюда, но это не совсем уникальный ответ, он слишком длинный для комментариев и включает код. Вы намекнули на неоднозначность, но ваш пример не выдвинул на первый план решающий случай. Я думаю, что пример, который вы привели, указывает на то, что может сбивать с толку, но требуемый {} вокруг инициализаторов объектов предотвращает основную синтаксическую неоднозначность. Мое объяснение следующего кода встроено в многострочный блочный комментарий.
[AttributeUsage(AttributeTargets.Class)]
public sealed class SomeAttribute : Attribute
{
public SomeAttribute() { }
public SomeAttribute(int SomeVariable)
{
this.SomeVariable = SomeVariable;
}
public int SomeVariable
{
get;
set;
}
}
/* Here's the true ambiguity: When you add an attribute, and only in this case
* there would be no way without a new syntax to use named arguments with attributes.
* This is a particular problem because attributes are a prime candidate for
* constructor simplification for immutable data types.
*/
// This calls the constructor with 1 arg
[Some(SomeVariable: 3)]
// This calls the constructor with 0 args, followed by setting a property
[Some(SomeVariable = 3)]
public class SomeClass
{
}
<Ч />