Зачем нужны скобки в статических конструкторах C#?

Учитывать:

class Foo
{
    static Foo()
    {
        // Static initialisation
    }
}

Почему () требуются в static Foo() {...}? Статический конструктор всегда должен быть без параметров, так зачем беспокоиться? Нужны ли они, чтобы избежать некоторой двусмысленности синтаксического анализатора, или просто для обеспечения согласованности с обычными конструкторами без параметров?

Поскольку он очень похож на блок инициализатора, я часто обнаруживаю, что случайно пропускаю их, а затем должен несколько секунд подумать, что не так. Было бы неплохо, если бы их можно было исключить таким же образом.


c# syntactic-sugar static-constructor
person verdesmarald    schedule 23.05.2011    source источник
comment
Если вам интересны такие аспекты языкового дизайна, вы можете прочитать мои статьи по аналогичной проблеме дизайна: blogs.msdn.com/b/ericlippert/archive/2010/09/20/   -  person Eric Lippert    schedule 23.05.2011
comment
@Eric Lippert: я уже заядлый читатель вашего блога (и я думаю, что именно там я узнал слово «пропущенный»). :) Однако, перечитывая эти статьи, кажется, что ни одна из двусмысленностей, созданных необязательными пустыми скобками в вызовах метода/конструктора, не применима к случаю статического конструктора (в основном потому, что вы не можете явно вызвать вещь). Есть ли в этом случае тоже двусмысленность, или дело просто в том, что оно того не стоит?   -  person verdesmarald    schedule 23.05.2011

Ответы (3)


arrow_upward
6
arrow_downward

Я часто получаю такого рода вопросы; то есть вопрос "компилятор мог отработать, что этой штуки не хватает, так зачем она нужна?" Вот еще один пример такого рода вопросов:

C# с использованием констант в статических классах

Как я отметил в этом вопросе, в основном у нас есть три варианта в этой ситуации. Сделайте избыточный текст обязательным, необязательным или недопустимым.

У каждого есть свой минус.

Обратной стороной обязательности является то, что вы получаете ненужную избыточность языка.

Недостатком того, что вы делаете его необязательным, является то, что вы сбиваете с толку людей, которые думают, что между этими двумя формами должна быть разница. Кроме того, вы усложняете работу синтаксического анализатора, восстанавливающего ошибки; он процветает за счет избыточности. И вы потенциально усложняете добавление новых языковых функций в будущем, потому что уже востребовано больше «синтаксической области».

Недостатком того, что вы делаете это незаконным, является то, что вы затем делаете «пойму», где пользователь должен помнить, что о, да, я должен ставить скобки здесь, но не здесь.

Предлагаемая функция должна иметь преимущество, которое компенсирует недостаток. Наименьший минус мне кажется первым: сделать его обязательным. Другие варианты, которые я хотел бы получить, оправдывают недостатки, и я не вижу их здесь.

person Eric Lippert    schedule 23.05.2011
comment
Интересно, что в случае static const вы пришли к выводу, что это просто больше набора текста без добавления ясности или выразительности языку, но в этом случае вы потенциально усложняете добавление новых языковых функций в будущем. Я предполагаю, что это случай того, сколько избыточности по сравнению с потерянным потенциалом? - person verdesmarald; 23.05.2011
comment
@veredesmarald: Да, каждый раз это приговор. В этом конкретном случае я думаю, что сделать его необязательным только в этом случае было бы странным несоответствием; почему бы не разрешить любому методу, не принимающему параметров, исключить список параметров? Что такого особенного в статических конструкторах? - person Eric Lippert; 23.05.2011
comment
Также интересно то, что вы упомянули, что сделать это незаконным, создает ошибку, в то время как я считаю, что ошибка должна включать их. Я думаю, что это комбинация моего частого использования инициализаторов с конструкторами без параметров, а также пережиток моих дней Java, где блоки static не имеют скобок. - person verdesmarald; 23.05.2011
comment
Как вы упомянули в своей серии, вы не можете сделать их необязательными для любого вызова, поскольку это приводит к двусмысленности; статические минусы особенные, поскольку упомянутые двусмысленности к ним не относятся (насколько я могу судить) из-за ограниченного количества мест, где они могут возникнуть. Я думаю, я могу купить угол несогласованности, хотя, на мой взгляд, статические минусы уже являются отдельным зверем по сравнению с обычными вызовами минусов/методов, возможно, это просто странность в том, как я рассматриваю аспекты языка. - person verdesmarald; 23.05.2011

arrow_upward
11
arrow_downward

Поскольку это статический конструктор, то это static + обычный конструктор.

Последовательность является ключевым фактором. :-)

person user541686    schedule 23.05.2011

arrow_upward
1
arrow_downward

Я бы предположил, что это для устранения неоднозначности: это упрощает работу синтаксического анализатора, распознавая блок кода как подпрограмму-конструктор (независимо от staticness); и, наоборот, это помогает гарантировать, что человек-автор/сопровождающий знает о последствиях выбора этой конкретной конструкции, заставляя их использовать определенный синтаксис, подобный методу.

person Matty K    schedule 23.05.2011