Предлагайте, создавайте новую дискуссию на гитхабе, обсуждайте… Если честно, я только представляю, как работает конвейер в микропроцессоре, но про такую функцию в языках программирования не слышал, поэтому сейчас не могу оценить, насколько она мне могла бы быть интересна и полезна.
'var' используется в польностью классическом понимании.
Вы мыслите шаблонно, PM так работает в других языках. Но что если предположить, что в C# может быть ещё лучше? Просто изучите новое предложение по улучшению синтаксиса языка. Вы можете найти в нём противоречия?
Хочу вас обрадовать. Ваш релизный код не сломается в контексте C# 8, он может перестать работать только для nullable value types (bool?, int?, etc.).
Конечно, это ваш выбор. Но я придерживаюсь той позиции, что PM в C# может быть ещё лучше, чем в других языках. Взгляните на следующее предложение по улучшению синтаксиса. Сколько всего красивого можно сделать…
Спасибо, что выражаете своё мнение и делитесь мыслями. Но у меня другое видение: 'var' — это только для вывода типа и не более. Без расширения его смысла можно прекрасно и гармонично обойтись, кроме того это позволит реализовать двусторонний матчинг.
Насчет кучи обсуждений — они вообще про другое, про трактовку `var` в языке с ненулевыми ссылочными типами.
Вот и я про то же — про трактовку 'var'. Моё мнение такое, 'var' следует использовать толко для вывода типов без навешивания дополнительной контекстнозависимой логики. Тогда это будет ясно, чисто, красиво.
Данный код ещё не в релизе, поэтому его можно ломать. Кстати, в процессе обсуждения образовалось и новое предложение по двустороннему матчингу, поэтому можете высказать и свои мысли на этот счёт.
Почему-то считается, что PM появился только в C# 7, но, на мой взгляд, отдельные его элементы в зачаточном виде присутствовали уже в более ранних версиях языка. Я говорю про инициализацию свойств в '{ X=1, Y=2}', а также про операторы 'is', 'as' и приведение типа. Новые фичи PM можно весьма гармонично вписать в прежний контекст.
Прежде чем принять решение, хорошо подумайте, поскольку тут есть достаточно веские «за» и «против». Не помешает и более подробное изучение вопроса и соответствующих дискусий.
Во-вторых, не большинства, а большого числа людей.
Может, для вас он очевиден, но для большого числа других людей, увы, нет.
Вам нужны примеры? Пожалуйста, не я один такой.
Вот вопрос про swich с большим рейтингом
Может, для вас он очевиден, но для большого числа других людей, увы, нет.
Почему вы хотите ВВЕСТИ в язык unexpected behaviour вместо уже имеющегося очевидного?
Ознакомьтесь детальнее с альтернативным предложением и вы увидете, что никакого unexpected behaviour оно не несёт, а наоборот выглядит гораздо более прозрачно.
Не спорю с тем, что поведение радикально меняется, но старый код (без изменений) будет работать по-прежнему, поэтому формально это не breaking change, обратная совместимость сохранена.
Конечно, для разработчика нововведение может выглядеть ужасно непредсказуемо и даже ломать его логиченые и интуитивные мыслительные шаблоны, как произошло у меня с 'var', но, скорее, это можно назвать pattern breaking. :)
Почему же неоднозначность? Ключевое слово 'any' без 'x' употребляться не может само по себе.
Более того, ради интереса сейчас проверил, можно ли объявить класс с именем 'var'. Можно! Всё компилируется, вот только 'var' в обычном значении перестаёт работать, поскольку воспринимается как тип, а ведь когда-то же и 'var' не было в C#.
Сейчас уже да, верно, но если бы 'any' было введено вместе с текущей реализацией pattern-matching'а, то синтаксис 'is any x' [где any — тип] был бы невалиден до того, поэтому введение ключевого слова в контексте нового синтаксиса ничего бы не поломало. По крайней мере, я не могу придумать пример, где бы это ещё могло проявиться.
Не совсем уловил суть примера, поэтому не буду комментировать.
Breaking change — это то, что ломает логику программы при компиляции на следующей весрсии языка (нарушение обратной совместимости). Можно добавить хоть десяток новых ключевых слов, но если старый код компилируется одинаково успешно, как на новой, так и на старой версиях языка, то никакого breaking change в классическом понимании не произошло. Просто расширился синтаксис и функционал, добавились новые ключевые слова и допустимые выражения с ними.
Сейчас, кажется, всё относительно консистентно, просто 'var' в разных контекстах имеет отличающийся смысл, что не интуитивно и иногда сбивает с толку. На мой взгляд, на консистентность не должно было бы повлиять введение новых ключевых слов для определённых контекстов.
Конечно, если добавлять новые ключевые слова уже сейчас, после релиза, то да — это breaking change. Но до момента релиза это ещё не breaking change :)
На мой взгляд, довольно очевидный вариант в контексте C# 8 может выглядеть так
if (GetPoint() is Point p) // всегда true
if (GetPoint() is Point? p) // true/false
if (GetPoint() is var p) // true/false, если метод возвращает Point?, только true, если Point
if (GetPoint() is null or Point p) // всегда true или неприминимо
if (GetPoint() is null or Point? p) // всегда true
if (GetPoint() is any p) // всегда true
Лично на мой взгляд, стоило ввести новое ключевое слово или добавить какой-то модификатор к 'var', а не просто подменять его значение, в зависимости от контекста использования. Тогда бы никаких неожиданностей не возникало.
Здесь предложено одно из решений проблемы, потенциально возможно и другое — усложнение логики компилятора (контроль null-ветвлений кода).
Однако с другой стороны — объявления переменных в классах также эквивалентны записи
поэтому такое решение тоже возможно.
Вы меня слышите? На 'null' проверяет оператор 'is', а не 'var'.
Не понимаю, что здесь нелогичного? Функция возвращает nullable string, компилятор выводит для переменной foo соответствующий тип. Эквивалентно
'var' используется в польностью классическом понимании.
Вы мыслите шаблонно, PM так работает в других языках. Но что если предположить, что в C# может быть ещё лучше? Просто изучите новое предложение по улучшению синтаксиса языка. Вы можете найти в нём противоречия?
Хочу вас обрадовать. Ваш релизный код не сломается в контексте C# 8, он может перестать работать только для nullable value types (bool?, int?, etc.).
Вот и я про то же — про трактовку 'var'. Моё мнение такое, 'var' следует использовать толко для вывода типов без навешивания дополнительной контекстнозависимой логики. Тогда это будет ясно, чисто, красиво.
Данный код ещё не в релизе, поэтому его можно ломать. Кстати, в процессе обсуждения образовалось и новое предложение по двустороннему матчингу, поэтому можете высказать и свои мысли на этот счёт.
Почему-то считается, что PM появился только в C# 7, но, на мой взгляд, отдельные его элементы в зачаточном виде присутствовали уже в более ранних версиях языка. Я говорю про инициализацию свойств в '{ X=1, Y=2}', а также про операторы 'is', 'as' и приведение типа. Новые фичи PM можно весьма гармонично вписать в прежний контекст.
Во-вторых, не большинства, а большого числа людей.
Вам нужны примеры? Пожалуйста, не я один такой.
Вот вопрос про swich с большим рейтингом
Куча предложений об одном и том же:
github.com/dotnet/csharplang/issues/792
github.com/dotnet/csharplang/issues/1192
github.com/dotnet/csharplang/issues/306
github.com/dotnet/csharplang/issues/1078
github.com/dotnet/csharplang/issues/1054
github.com/dotnet/csharplang/issues/1203
Ознакомьтесь детальнее с альтернативным предложением и вы увидете, что никакого unexpected behaviour оно не несёт, а наоборот выглядит гораздо более прозрачно.
Конечно, для разработчика нововведение может выглядеть ужасно непредсказуемо и даже ломать его логиченые и интуитивные мыслительные шаблоны, как произошло у меня с 'var', но, скорее, это можно назвать pattern breaking. :)
Более того, ради интереса сейчас проверил, можно ли объявить класс с именем 'var'. Можно! Всё компилируется, вот только 'var' в обычном значении перестаёт работать, поскольку воспринимается как тип, а ведь когда-то же и 'var' не было в C#.
Breaking change — это то, что ломает логику программы при компиляции на следующей весрсии языка (нарушение обратной совместимости). Можно добавить хоть десяток новых ключевых слов, но если старый код компилируется одинаково успешно, как на новой, так и на старой версиях языка, то никакого breaking change в классическом понимании не произошло. Просто расширился синтаксис и функционал, добавились новые ключевые слова и допустимые выражения с ними.
Конечно, если добавлять новые ключевые слова уже сейчас, после релиза, то да — это breaking change. Но до момента релиза это ещё не breaking change :)