def d = ["str"]
def g = d.Find(x => x == "") ?? null
ошибки
C:\MyProjects\NTest\Main.n(17,37): error : Can't infer type of right operand (null) of the `??' operator
C:\MyProjects\NTest\Main.n(17,13): error : typing fails on delayed macro
Здравствуйте, _Claus_, Вы писали:
_C_>def d = ["str"] _C_>def g = d.Find(x => x == "") ?? null
Наверно это какая-то проблема в компиляторе или макросе. Но сам код — это пипец!
Зачем option[T] в null превращать?
Используй FindObject, если тебе нужен null. Но FindObject сделан для тех случаев когда важно минимизировать накладные расходы (для скорости). option[T] защищает от ошибок. А ты используешь метод возвращающий option[T] и при этом сразу же делаешь все чтобы убить все преимущества которые он дает. Еще раз повторюсь — пипец!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Используй FindObject, если тебе нужен null. Но FindObject сделан для тех случаев когда важно минимизировать накладные расходы (для скорости). option[T] защищает от ошибок. А ты используешь метод возвращающий option[T] и при этом сразу же делаешь все чтобы убить все преимущества которые он дает. Еще раз повторюсь — пипец!
конечно мой код вообще другой. пример для упрощения. многие методы дают option, а мне для стыковки нужен указатель или Nullable.
было здорово по максимуму стереть эту разницу, чтобы компилятор занимался приведениями. ведь фактически речь об одном и том же,
и пляски вокруг этого утомительны и раздражительны. внимание к мелочам — признак серьезного продукта.
Здравствуйте, _Claus_, Вы писали:
_C_>конечно мой код вообще другой. пример для упрощения. многие методы дают option, а мне для стыковки нужен указатель или Nullable. _C_>было здорово по максимуму стереть эту разницу, чтобы компилятор занимался приведениями. ведь фактически речь об одном и том же, _C_>и пляски вокруг этого утомительны и раздражительны. внимание к мелочам — признак серьезного продукта.
_C_>добавить в Issues?
Неявное проведение от option[T] к T? Такого в Немерле не будет, по крайней мере, пока я им занимаюсь.
Используй проверки наличия значения (match, when, if).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Неявное проведение от option[T] к T? Такого в Немерле не будет, по крайней мере, пока я им занимаюсь.
VD>Используй проверки наличия значения (match, when, if).
меня устроит если ?? и ?. будут адекватно реагировать.
+ разумно было было option мог сравниваться с T. этого бы хватило.
VD>Неявное проведение от option[T] к T? Такого в Немерле не будет, по крайней мере, пока я им занимаюсь.
VD>Используй проверки наличия значения (match, when, if).
еще, чисто для увеличения скорости, чтобы компилятор не создавал объекты option для референсных типов,
разумна была бы при компиляции регрессия к обычным указателям. а для value-типов, для .Net совместимости,
к Nullable. последнее было удобно для использования библиотек вне Nemerle.
Здравствуйте, _Claus_, Вы писали:
VD>>Используй проверки наличия значения (match, when, if).
_C_>меня устроит если ?? и ?. будут адекватно реагировать. _C_>+ разумно было было option мог сравниваться с T. этого бы хватило.
_C_>добавить в Issues?
Для ?? поддержка опшона вроде есть. Для ?. ее можно попробовать добавить, но это может оказаться проблематичным.
Что касается операторов, то можно сделать воспроизведение операторов имеющихся у T для значений завертутых в option. Не так давно я подобную фигню реализовал для Nullable-типов. Так что сделать это для опшонов будет не сложно. Но только оперировать они будут не над T и option[T], а для option[T] и option[T], т.е. второе значени надо будет так же поднимать в option[T]. И результатом у них будет так же option[T]. Для == и != можно сделать исключение и возвращать bool. Хотя это и чревато.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Для ?? поддержка опшона вроде есть.
как показывает пример, там не все гладко.
VD> Для ?. ее можно попробовать добавить, но это может оказаться проблематичным.
я туда смотрел. моих знаний маловато, чтобы править. твоих, уверен, хватит.
VD>Что касается операторов, то можно сделать воспроизведение операторов имеющихся у T для значений завертутых в option. Не так давно я подобную фигню реализовал для Nullable-типов. Так что сделать это для опшонов будет не сложно. Но только оперировать они будут не над T и option[T], а для option[T] и option[T], т.е. второе значени надо будет так же поднимать в option[T]. И результатом у них будет так же option[T]. Для == и != можно сделать исключение и возвращать bool. Хотя это и чревато.
Здравствуйте, _Claus_, Вы писали:
VD>> Для ?. ее можно попробовать добавить, но это может оказаться проблематичным. _C_>я туда смотрел. моих знаний маловато, чтобы править. твоих, уверен, хватит.
VD>>Что касается операторов, то можно сделать воспроизведение операторов имеющихся у T для значений завертутых в option. Не так давно я подобную фигню реализовал для Nullable-типов. Так что сделать это для опшонов будет не сложно. Но только оперировать они будут не над T и option[T], а для option[T] и option[T], т.е. второе значени надо будет так же поднимать в option[T]. И результатом у них будет так же option[T]. Для == и != можно сделать исключение и возвращать bool. Хотя это и чревато.
_C_>это было бы здорово!
У меня сейчас времени на мелочи вроде этих нет. Могу сказать куда копать (что делать) и консультировать по ходу дела. Только чур соблюдать правила форматирования и без экстрима разного.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
