Сегодня с _nn_ во время традиционного замера пиписек с ультракоротким языком заметили. Присваивание с bitwise-логикой реализовано, а с булевой — нет. Набросал макры с этими операциями по аналогии с bitwise — все вроде работает, ничего ни с чем не конфликтует.
Просто забыли, нафиг не было нужно или есть причины? А то как-то нелогично получается
Здравствуйте, catbert, Вы писали:
C>А нафиг оно нужно?
Код сокращает аж на целое имя переменной и пару операторов пробела Мне просто кажется, что оно нужно так же, как и уже реализованные bitwise-присваивания, т.е. либо они есть все (и bitwise и булевы), либо их нет.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Сегодня с _nn_ во время традиционного замера пиписек с ультракоротким языком заметили. Присваивание с bitwise-логикой реализовано, а с булевой — нет. Набросал макры с этими операциями по аналогии с bitwise — все вроде работает, ничего ни с чем не конфликтует.
KV>Просто забыли, нафиг не было нужно или есть причины? А то как-то нелогично получается
А &&=, как и &&, не вычисляет выражение если значение переменной false? Не будет ли это удивлять?
mutable x = false;
x &&= functionWithSideEffectsTheWillNotBeCalled()
Re[2]: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Код сокращает аж на целое имя переменной и пару операторов пробела Мне просто кажется, что оно нужно так же, как и уже реализованные bitwise-присваивания, т.е. либо они есть все (и bitwise и булевы), либо их нет.
Не понимаю... && это ведь тот же самый оператор, что и &, только ленивый?
Re[3]: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, RomikT, Вы писали:
RT>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Сегодня с _nn_ во время традиционного замера пиписек с ультракоротким языком заметили. Присваивание с bitwise-логикой реализовано, а с булевой — нет. Набросал макры с этими операциями по аналогии с bitwise — все вроде работает, ничего ни с чем не конфликтует.
KV>>Просто забыли, нафиг не было нужно или есть причины? А то как-то нелогично получается
RT>А &&=, как и &&, не вычисляет выражение если значение переменной false? Не будет ли это удивлять? RT>
RT>mutable x = false;
RT>x &&= functionWithSideEffectsTheWillNotBeCalled()
RT>
Хороший вопрос. Да, по логике, являясь сахаром для x = x && functionWithSideEffectsTheWillNotBeCalled(), в приведенном примере значение ф-ции не должно вычисляться, но WTF'ы на эту тему будут обязательно. Ну, тогда можно пойти по пути шарпа и, оставив все как есть, просто реализовать operator_bitwiseAnd(bool, bool). А то получается и не так (симметричная реализация) и не эдак (как в шарпе).
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Код сокращает аж на целое имя переменной и пару операторов пробела Мне просто кажется, что оно нужно так же, как и уже реализованные bitwise-присваивания, т.е. либо они есть все (и bitwise и булевы), либо их нет.
C>Не понимаю... && это ведь тот же самый оператор, что и &, только ленивый?
Нет. По крайней мере, на практике. В шарпе они действительно отличаются только ленивостью, т.к. оба определены как над целыми, так и над булевыми типами. В немерле, & определен только над целыми, а && только над булевыми (установил эмпирически, в исходники не смотрел). Т.е. вот такой код не скомпилируется:
mutable A = 0;
A = A && 1; // ошибка "expected bool, got int- in matched value: System.Int32 is not a subtype of System.Boolean [simple require]"mutable B = true;
B = B & true; // ошибка "typing fails on finding the operator op_BitwiseAnd(bool, bool)"
Т.е. в немерле & и && это один и тот же оператор для различных типов, но при этом еще и первый энергичный, а второй ленивый, судя по всему. И &= есть, а &&= нет
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, catbert, Вы писали:
C>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Код сокращает аж на целое имя переменной и пару операторов пробела Мне просто кажется, что оно нужно так же, как и уже реализованные bitwise-присваивания, т.е. либо они есть все (и bitwise и булевы), либо их нет.
C>>Не понимаю... && это ведь тот же самый оператор, что и &, только ленивый?
KV>Нет. По крайней мере, на практике. В шарпе они действительно отличаются только ленивостью, т.к. оба определены как над целыми, так и над булевыми типами.
Не совсем так.
&& и || определены только для bool.
KV>В немерле, & определен только над целыми, а && только над булевыми (установил эмпирически, в исходники не смотрел). Т.е. вот такой код не скомпилируется:
А вот тут надо бы добавить & и | для bool.
Полным набором для bool:
&, &=, &&, &&=
|, |=, ||, ||=
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Сегодня с _nn_ во время традиционного замера пиписек с ультракоротким языком заметили. Присваивание с bitwise-логикой реализовано, а с булевой — нет. Набросал макры с этими операциями по аналогии с bitwise — все вроде работает, ничего ни с чем не конфликтует.
KV>Просто забыли, нафиг не было нужно или есть причины? А то как-то нелогично получается
Видимо, сделали по аналогии с шарпом.
Help will always be given at Hogwarts to those who ask for it.
Re: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Да, по логике, являясь сахаром для x = x && functionWithSideEffectsTheWillNotBeCalled(), в приведенном примере значение ф-ции не должно вычисляться, но WTF'ы на эту тему будут обязательно.
Может в таком случае ворнинги стоит выдавать? Хотя макрос тогда наверное будет много сложнее.
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Re[4]: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, Rival, Вы писали:
R>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Да, по логике, являясь сахаром для x = x && functionWithSideEffectsTheWillNotBeCalled(), в приведенном примере значение ф-ции не должно вычисляться, но WTF'ы на эту тему будут обязательно.
R>Может в таком случае ворнинги стоит выдавать? Хотя макрос тогда наверное будет много сложнее.
Выдать предупреждения в макросе не проблема.
Но зачем.
Просто запомнить, что двойные символы дают ленивое вычисление.
Здравствуйте, _NN_, Вы писали:
R>>Может в таком случае ворнинги стоит выдавать? Хотя макрос тогда наверное будет много сложнее. _NN>Выдать предупреждения в макросе не проблема. _NN>Но зачем.
_NN>Просто запомнить, что двойные символы дают ленивое вычисление.
Ну для меня это не проблема и ворнинги мне не нужны но kochetkov.vladimir написал опасение что:
KV>>>в приведенном примере значение ф-ции не должно вычисляться, но WTF'ы на эту тему будут обязательно.
Ворнинги вариант решения этой проблемы.
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Re[6]: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, Ziaw, Вы писали:
Z>Ворнинг плохой вариант, если программист желает именно ленивого поведения.
Да.
Тогда можно завести какой-нибудь дефайн препроцессора для таких случаев.
Правда если включить по умолчанию, всем его придётся отключать, а если не включать, то скорее всего люди, которые не ожидают ленивого поведения, не будут знать об этом флаге, пока не наткнутся на "WTF".
Насколько много в Немерле мест, где поведение Немерле расходится или может расходиться с ожидаемым поведением для С# программиста?
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Re: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Сегодня с _nn_ во время традиционного замера пиписек с ультракоротким языком заметили. Присваивание с bitwise-логикой реализовано, а с булевой — нет. Набросал макры с этими операциями по аналогии с bitwise — все вроде работает, ничего ни с чем не конфликтует.
KV>Просто забыли, нафиг не было нужно или есть причины? А то как-то нелогично получается
Похоже действительно вряд ли найдутся случаи использования этого оператора, наверное у создателей С# тоже были причины не включать их. Вообще не очень хороший стиль производить булевое выражение и его присваивать результату, это и не функциональный стиль, получается слева должно быть обязательно mutable переменная.
Пулл реквест был отклонен, пока полного согласия сообщества еще не видно, он создан поспешно. Надо серьезно подумать чтобы что то добавлять, чтобы язык не превратился в реализацию множества чьих то хотелок. Для таких случаев даже в boost библиотеки проходят долгий период обсуждения и проверок. Если кому то очень хочется иметь такие операторы, то можно в собственных библиотеках их реализовывать, но в стандартную над 100 раз подумать.
Re[2]: А почему &= и им подобные реализованы, а &&= нет?
Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Сегодня с _nn_ во время традиционного замера пиписек с ультракоротким языком заметили. Присваивание с bitwise-логикой реализовано, а с булевой — нет. Набросал макры с этими операциями по аналогии с bitwise — все вроде работает, ничего ни с чем не конфликтует.
KV>>Просто забыли, нафиг не было нужно или есть причины? А то как-то нелогично получается
CU>Похоже действительно вряд ли найдутся случаи использования этого оператора, наверное у создателей С# тоже были причины не включать их.
То, что они не включены в C# еще не повод не включать в Nemerle.
Примеры: ** , %&&, %||, %^^, <-> .
CU>Вообще не очень хороший стиль производить булевое выражение и его присваивать результату, это и не функциональный стиль, получается слева должно быть обязательно mutable переменная.
Функциональность стиля у "&&=" точно такая же как и у "+=".
CU> Пулл реквест был отклонен, пока полного согласия сообщества еще не видно, он создан поспешно. Надо серьезно подумать чтобы что то добавлять, чтобы язык не превратился в реализацию множества чьих то хотелок. Для таких случаев даже в boost библиотеки проходят долгий период обсуждения и проверок. Если кому то очень хочется иметь такие операторы, то можно в собственных библиотеках их реализовывать, но в стандартную над 100 раз подумать.
На мой взгляд есть просто потеря симметрии.