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

__>Еще интереснее, что следующий код имеет неосторожность компилироваться:
А вот нечего использовать фичи только потому, что их ввели. Ввели в основном для паритета с VB и интеропа к кошмарному ворду.

В саппорте оно ещё хуже, чем var выходит.

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

__> Я уже вроде все объяснил

Я просто подумал может оно и приведение типов тогда не контролирует, весело бы было.

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

S>А вот нечего использовать фичи только потому, что их ввели. Ввели в основном для паритета с VB и интеропа к кошмарному ворду.
это сейчас к чему было сказано?

S>В саппорте оно ещё хуже, чем var выходит.
var как раз весьма полезен, особенно если у типов сущностей длинные идентификаторы. Еще бы они работали для лямбд и анонимных методов — было бы просто шикарно.

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

H>Когда это C# упорно копировал С++? Скорее уж Delphi, в котором аргументы со значением по умолчанию были всегда. Правда, как в аналогичном лучае dcc32 поступает, судить не берусь ибо не помню, а под рукой его нет.

Попробовал в Delphi6 (Object Pascal) — компилятор на строчке вызова foo(); ругается "Ambiguous overloaded call to 'foo'".

Посему следующая гипотеза: логика в C# скопирована с VB, где тоже аргументы со значением по умолчанию поддерживаются издревле.

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

__>это сейчас к чему было сказано?
К тому, что не всякое нововведение ориентировано на применение в майнстриме, и, соответственно, должно использоваться с умом и пониманием, что "здесь отстреливают ноги"

__>var как раз весьма полезен, особенно если у типов сущностей длинные идентификаторы. Еще бы они работали для лямбд и анонимных методов — было бы просто шикарно.

var мегаполезен в прототипировании и в самплах. В продакшне лучше явно декларировать типы: проще читать чужой код, проще рефакторить. Рассказывали байку, что благодаря var какое-то время не падал код с

// было
public string SomeVal() {}
// стало
public int SomeVal() {}

А потом библиотеку задеплоили на клиента Не, ССЗБ и всё такое, но лучше уж не полениться один раз, чем бегать от клиентов в дальнейшем.

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

S>var мегаполезен в прототипировании и в самплах. В продакшне лучше явно декларировать типы: проще читать чужой код, проще рефакторить.
Читать, по-моему, сложнее, потому что длинные идентификаторы с двух сторон весьма замусоривают код.
Рефакторить тоже сложнее. У меня был случай, когда в процессе разработки один метод стал возвращать значение другого типа. Пришлось везде, где результат этого метода присваивался к переменной, поменять ее тип вручную.

S>Рассказывали байку, что благодаря var какое-то время не падал код с
S>

S>// было
S>public string SomeVal() {}
S>// стало
S>public int SomeVal() {}
S>

S>А потом библиотеку задеплоили на клиента Не, ССЗБ и всё такое, но лучше уж не полениться один раз, чем бегать от клиентов в дальнейшем.
Можно пример, как такое возможно?

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

D>Читать, по-моему, сложнее, потому что длинные идентификаторы с двух сторон весьма замусоривают код.

var a2 = a.Foo()

Читать сложнее — приходится выделять ресурсы на вывод типов

D>Рефакторить тоже сложнее. У меня был случай, когда в процессе разработки один метод стал возвращать значение другого типа.
Так в этом весь цимес: вы видите, как используется ваш код — у вас больше шансов обнаружить, что рефакторинг делается неверно

Это обычный холивар статика vs динамика — либо мучаемся с явным описанием контрактов, либо нарываемся на нарушения контракта в рантайме. Разумеется, выбираем что важнее/удобнее.

D>Можно пример, как такое возможно?
Например так:

// Assembly1
public int Foo() { } // было public string Foo() { }

// Assembly1.Tests
var x = a.Foo();
Debug.Assert(x != null); // конечно, будет варнинг. Но мы его как бы не заметим.

// ClientAssembly
int b = Foo()[3]; // Вуаля;)

При условии, что ClientAssembly не пересобиралась.

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

S>Это обычный холивар статика vs динамика — либо мучаемся с явным описанием контрактов, либо нарываемся на нарушения контракта в рантайме. Разумеется, выбираем что важнее/удобнее.
как связаны var и динамическая типизация? (Ответ: никак)

D>>Можно пример, как такое возможно?
S>Например так:
S>[c#]
S>// Assembly1
S>public int Foo() { } // было public string Foo() { }

S>// Assembly1.Tests
S>var x = a.Foo();
S>Debug.Assert(x != null); // конечно, будет варнинг. Но мы его как бы не заметим.

Он будет и без всякого var. Кроме того, в релизе, нужно все warnings перековывать на errors.
Так что это уже проблема культуры билдинга и релизинга, принятой в вашей организации — не более того.

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

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

D>>Читать, по-моему, сложнее, потому что длинные идентификаторы с двух сторон весьма замусоривают код.
S>

S>var a2 = a.Foo()
S>

S>Читать сложнее — приходится выделять ресурсы на вывод типов

Если код грамотно написан, переменные имеют "длинные мнемонические имена", то знание имен типов конкретных переменных совершенно не нужно на этапе чтения и понимания кода.

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

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

S>>Это обычный холивар статика vs динамика — либо мучаемся с явным описанием контрактов, либо нарываемся на нарушения контракта в рантайме. Разумеется, выбираем что важнее/удобнее.
__>как связаны var и динамическая типизация? (Ответ: никак)

Как связано ваше утверждение и моё? *хинт: где я заикнулся о компиляции?

__>Он будет и без всякого var. Кроме того, в релизе, нужно все warnings перековывать на errors.
Байка не моя, так что не в курсе что там было на самом деле.

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

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

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

S>>>Это обычный холивар статика vs динамика — либо мучаемся с явным описанием контрактов, либо нарываемся на нарушения контракта в рантайме. Разумеется, выбираем что важнее/удобнее.
__>>как связаны var и динамическая типизация? (Ответ: никак)

S>Как связано ваше утверждение и моё? *хинт: где я заикнулся о компиляции?

либо мучаемся с явным описанием контрактов, либо нарываемся на нарушения контракта в рантайме.

var — это и есть явное описание контрактов

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

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

D>>Читать, по-моему, сложнее, потому что длинные идентификаторы с двух сторон весьма замусоривают код.
S>

S>var a2 = a.Foo()
S>

S>Читать сложнее — приходится выделять ресурсы на вывод типов

Такой пример — фигня: навел мышкой на a2 и студия показала ху из ху.
Страшнее когда десяток локальных функций и ни у одной из них не объявлен тип аргументов, вот где нужны ресурсы.