class Program
{
  public static (int First, string Second) TupleField;

  static (int x, string y) Tuple;

  static ref (int x, string y) var(int x, string y)
  {
    return ref Tuple;
  }

  static ref (int x, string y) Foo(int x, string y)
  {
    return ref Tuple;
  }

  static void Main()
  {
    var tuple = (42, "b");

    var(a, b) = tuple; // объявление двух локальных переменных.
    Foo(a, b) = tuple; // а здесь вызов метода!
    var(a, b);         // и здесь вызов метода! Не путать! :)
  }
}

Вот на хрена сначала было делать var контекстным ключевым словом, а потом делать исключения для него?

Причем на выпуск спецификаций C# Microsoft забил, так что описание всей этой магии отсутствует. Если я не прав, бросьте в меня ссылкой.

Сейчас пилю поддержку фич 7-го Шарпа на Nitra. Приходится заниматься реверс-инжинирингом логики этих бравых парней.

Здравствуйте, VladD2, Вы писали:

VD>Вот на хрена сначала было делать var контекстным ключевым словом, а потом делать исключения для него?
Потому оно не с начала было ключевым словом.

Влад, у вас профессиональная деформация. Уж извините. Но кому придет в голову называть метод var. Или называть его Foo. Вы берите примеры из жизни, реальный код и проблем таких не будет.

Здравствуйте, alexzzzz, Вы писали:

A>Потому оно не с начала было ключевым словом.

Ну, и что? Все спокойно переименовали бы свои var-ы во что-то другое. Все равно на 100% совместимость обеспечить не удается.

Здравствуйте, Gattaka, Вы писали:

G>Влад, у вас профессиональная деформация. Уж извините. Но кому придет в голову называть метод var. Или называть его Foo. Вы берите примеры из жизни, реальный код и проблем таких не будет.

Ну, дак, раз никому не приходит, то почему бы было не сделать его ключевым словом (не контекстным)?

Просто в МС сделали var контекстным из соображений совестимости. А кому она нужна, такая совместимость? В итоге им пришлось вводить дополнительные правила, которые они даже не удосужились нигде описать.

Здравствуйте, VladD2, Вы писали:

VD>Ну, и что? Все спокойно переименовали бы свои var-ы во что-то другое.

Саботаж. Кому нужен язык, у которого каждая новая версия не совместима с существующем кодом?
В 3.0 var, в 4.0 dynamic, в 5.0 async, в 6.0 nameof, в 7.0 _ ― они все контекстные.

Здравствуйте, VladD2, Вы писали:

VD>В итоге им пришлось вводить дополнительные правила, которые они даже не удосужились нигде описать.

Параграфы 2.4.3 и 8.5.1 спецификации C# 5.0 или (1) и (2) в черновике спецификации C# 6.0.

Здравствуйте, alexzzzz, Вы писали:

A>Саботаж. Кому нужен язык, у которого каждая новая версия не совместима с существующем кодом?
A>В 3.0 var, в 4.0 dynamic, в 5.0 async, в 6.0 nameof, в 7.0 _ ― они все контекстные.

Она по факту и так не совместима. Но это никого не интересует. По сути никто не называет типы или методы со строчной буквы. Так что никто и не мог налететь на несовместимость. А var может применяться только в тех местах где ожидается тип.

Так что с var смысла выпендриваться не было.

Случай с типом имеющим название var — настолько гипотетический, что на него можно и забить.

По крайней мере РеШарпер этот случай не учитывает, но всем по фиг. Эта багу даже не стали испрвлять. Траха много, а толку нет. Так что решарпер считает var ключевым словом, по сути.

Здравствуйте, alexzzzz, Вы писали:


A>Параграфы 2.4.3 и 8.5.1 спецификации C# 5.0 или (1) и (2) в черновике спецификации C# 6.0.

А зачем мне 5 и 6? Мне нужна спека по 7.

Это же просто бардак! Уже зерелизили 7-ю версию, а спека по 6 имеется только в черновике. Причем я как очевидец подтверждаю, что реальной грамматике она не соответствует. Хотя и не сильно.

Здравствуйте, alexzzzz, Вы писали:

A>Саботаж. Кому нужен язык, у которого каждая новая версия не совместима с существующем кодом?
A>В 3.0 var, в 4.0 dynamic, в 5.0 async, в 6.0 nameof, в 7.0 _ ― они все контекстные.

Возможно я непонятно выразился. Дело даже не в котекстности этих самых недоключевых слов. Дело в тех правилах-костылях которые они ввели для "типа" совместимости.

Тот же var в позиции типа был бы вполне себе однозначным, если бы они не пытались обойти современно гипотетический (не встречающийся на практике) случай с типом имеющим имя var. Локальные переменные с именем var проблем не вызвают, так как тип и имена локальных переменных по грамматике не пересекаются.

Сделав этот костыль (т.е. позолив использовать типы с именем var) они создали себе просто для дальнейшего костылестроения. В C#7 вот пришлось вводить правило, что var(f, b) — это ни фига не вызов, а декомпозиция кортежа. Причем в одном случае это правило работает, а в другом нет.

Надо было делать var контекстным ключевым словом, но без этих выкрутасов "а если есть тип var, то var не ключевое слово, а тип). var в позиции типа => это объявление переменной. Вот тогда бы все было просто и дизайн не был бы запутан.

Здравствуйте, VladD2, Вы писали:

VD>Тот же var в позиции типа был бы вполне себе однозначным, если бы они не пытались обойти современно гипотетический (не встречающийся на практике) случай с типом имеющим имя var.
Это в текущем C# переменные с именем var не вызывают проблем. В твоём варианте C# все они стали ты невозможны, как невозможны переменные class или object. А раз и так var пришлось делать контекстным, то объяснение Липперта «we prefer to avoid as many breaking changes as possible» меня вполне устраивает.

VD>Локальные переменные с именем var проблем не вызвают, так как тип и имена локальных переменных по грамматике не пересекаются.
Возможно, раньше не пересекались, сейчас пересекаются ― nameof(var)

Здравствуйте, alexzzzz, Вы писали:

A>Это в текущем C# переменные с именем var не вызывают проблем. В твоём варианте C# все они стали ты невозможны, как невозможны переменные class или object. А раз и так var пришлось делать контекстным, то объяснение Липперта «we prefer to avoid as many breaking changes as possible» меня вполне устраивает.

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

A>Возможно, раньше не пересекались, сейчас пересекаются ― nameof(var)

Ты точно подумал прежде чем пример привел? Как раз в случае запрета использования слова var в качестве типа никаких проблем бы не было. Получать имя ключевого слова нет смысла. Значит var — это точно имя переменной или ошибка.

Здравствуйте, VladD2, Вы писали:

A>>Это в текущем C# переменные с именем var не вызывают проблем. В твоём варианте C# все они стали ты невозможны, как невозможны переменные class или object. А раз и так var пришлось делать контекстным, то объяснение Липперта «we prefer to avoid as many breaking changes as possible» меня вполне устраивает.

VD>Ты то ли не читаешь, что я тебе пишу, то ли не можешь понять прочитанное. Попробуй еще раз. Дело не в контекстности. Дело в дурацких, никому ненужных правилах в стиле "здесь играем, здесь не играем, а здесь мы рыбу заворачивали" (ц).

Правила такие не для красоты и не для «типа» совместимости, а для Совместимости. Одно дело, когда ты берёшь новый компилятор, компилируешь старые исходники и получаешь рабочий код, а потом в рабочих исходниках меняешь имя типу var на что-нибудь другое. Другое дело, когда ты берёшь новый компилятор, компилируешь старые исходники и получаешь букву хер, и пока не поменяешь имя типа везде, ничего не заработает.

Запись же var(a,b) = ... выглядит как очевидная декомпозиция и ею является. Сохранять совместимость тут не требуется. Нет смысла искать существующий метод var, возвращающий ссылку, потому что до версии 7.0 методы не могли возвращать ссылки. Любой валидный старый код, даже с методом по имени var, останется валидным и скомпилируется без проблем.

Правила, возможно, и не самые некрасивые, но осмысленные. По мне, лучше так, чем наоборот. С точки зрения совместимости они консистентны.

A>>Возможно, раньше не пересекались, сейчас пересекаются ― nameof(var)
VD>Ты точно подумал прежде чем пример привел? Как раз в случае запрета использования слова var в качестве типа никаких проблем бы не было. Получать имя ключевого слова нет смысла. Значит var — это точно имя переменной или ошибка.

Каких проблем бы не было? Если имя есть в области видимости, nameof даст это имя; если нет, ошибку. Неважно, var там или ещё что (кроме метода nameof ).

Здравствуйте, Gattaka, Вы писали:

G>Но кому придет в голову называть метод var.
Писателям кодогенераторов, потому что на самом деле нет никаких приград в том чтобы назвать переменную словом var, а так же var1, var2, var3...

Здравствуйте, VladD2, Вы писали:

Я так понимаю async async async(async async)

Автор: Ziaw
Дата: 19.04.17

вопросов не вызвал совсем, а тут какой-то один var

Меня удивляет, что ты до сих пор возишься с этим творением MS.

Здравствуйте, vaskir, Вы писали:

V>Меня удивляет, что ты до сих пор возишься с этим творением MS.

Какбудто есть достойные альтернативы.