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

VD>Речь идет о сравнении двух объектов. Если у них еще к тому же переопределены GetHashcode и Equals — это почти наверняка ошибка. Если это делается намеренно, то лучше это явно указать.

Оффтоп: большинство предложений в рослиновских репо так и выглядят.
Народ вечно забывает про сложные части (ну или просто про них не знает, тоже бывает) и начинает яростно настаивать на простых, очевидных и неправильных решениях

По теме — double. Там по определению (NaN==NaN) != NaN.Equals(NaN).
И для эстетов,

int? a = null;
int? b = 5;
if (a <= b == Comparer<int?>.Default.Compare(a, b) <= 0) // что не так-то?
  ...

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

VD>>Речь идет о сравнении двух объектов. Если у них еще к тому же переопределены GetHashcode и Equals — это почти наверняка ошибка. Если это делается намеренно, то лучше это явно указать.

S>Оффтоп: большинство предложений в рослиновских репо так и выглядят.
S>Народ вечно забывает про сложные части (ну или просто про них не знает, тоже бывает) и начинает яростно настаивать на простых, очевидных и неправильных решениях

С тобой практически невозможно спорить. Ты априори прав. Ведь ты сам определяешь, что предложение неправильное, а такими мелочами, как аргументация себя не утруждаешь.

Я, вот, с тобой и спорить не хочу. Я уже более 10 лет пользуюсь языком где "неправильные" предложения отлично работают на практике и оберегают от ряда ошибок. Вот на фига мне тебе что-то доказывать? Продолжай считать правильным только то, что апрувнуто МС и пиши очередные WHF.

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

VD>С тобой практически невозможно спорить. Ты априори прав. Ведь ты сам определяешь, что предложение неправильное, а такими мелочами, как аргументация себя не утруждаешь.
Ок, принято
Неправильные — не совсем правильное слово. Могу заменить на "в итоге не будут работать без поломки совместимости с существующим .net-кодом", тогда вроде всё верно.

VD>Я, вот, с тобой и спорить не хочу. Я уже более 10 лет пользуюсь языком где "неправильные" предложения отлично работают на практике и оберегают от ряда ошибок. Вот на фига мне тебе что-то доказывать? Продолжай считать правильным только то, что апрувнуто МС и пиши очередные WHF.
Ну так у тебя и нет тяжкого наследия в виде кучи легаси, необходимости дизайна под 95% community и нужды сохранять совместимость с кодом, написанным 17 лет назад, верно?
Народ в .Net Core уже попытался пойти таким путём. Два года это как бы работало, а потом внезапно пришёл фидбэк от крупных клиентов. В итоге ещё два года аврала и у нас снова почти совместимый с .full net FW.

Не в порядке спора, реально интересно: а как ещё в языке одновременно реализовать sql-style операторы для nullables и при этом не поломать словари/sorted set?
Или делаем так, чтобы реализации операторов и стандартных equatable/comparable-интерфейсов не совпадали, или продолжаем наступать на грабли.

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

AVK>>Да уж точно. Замена 100500 проверок на null в коде на ReferenceEquals — это прекрасная идея. В Nemerle как, запретил уже?
VD>А причем тут проверка на null? С ней, как раз, никаких проблем нет. Ну, кроме того, что в 90% случаев — это бойлерплэйт-код, который приходится писать из-за убогости языков. null — это специальный литерал. Второй операнд у "х != null" можно автоматом к object приводить.

Так запретил уже в Немерле или как?

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

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

VD>>Речь идет о сравнении двух объектов. Если у них еще к тому же переопределены GetHashcode и Equals — это почти наверняка ошибка. Если это делается намеренно, то лучше это явно указать.

S>Оффтоп: большинство предложений в рослиновских репо так и выглядят.
S>Народ вечно забывает про сложные части (ну или просто про них не знает, тоже бывает) и начинает яростно настаивать на простых, очевидных и неправильных решениях

Насколько я понимаю, Влад предлагает запрет только для ссылочных типов.
Тогда однозначно a == b будет вызывать operator==, или не будет компилироваться если его нет.
А если нужно ссылочное сравнение, то явно object.ReferenceEquals(a, b) или явное приведение к object: (object)a == b

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

AVK>Так запретил уже в Немерле или как?

Ворнинг на ссылочное сравнение типов не приведенных к object — есть. А для null исключения нет. Но — это хорошая идея. Надо будет сделать.

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


_NN>Насколько я понимаю, Влад предлагает запрет только для ссылочных типов.
_NN>Тогда однозначно a == b будет вызывать operator==, или не будет компилироваться если его нет.
Неа, всё та же ловушка Вроде всё просто и очевидно, на деле нельзя будет сравнивать с null + будет очень неочевидное поведение для dynamic.