NI
auto value = pObject?->value;
value тут std::optional<decltype(value)>
value тут std::optional<decltype(value)>
Size: a a a
2020 August 05
DF
Optional<reference_wrapper> уже озвучивали?
NI
имхо это было бы оч удобно
NI
разворачивается в
std::optional<decltype(MyObject::value)> value = std::nullopt;
if(pObject)
value = pObject->value;
std::optional<decltype(MyObject::value)> value = std::nullopt;
if(pObject)
value = pObject->value;
NI
работает для всего с определенными неявной конверсией в bool и operator*/->
m
auto value = pObject?->value;
value тут std::optional<decltype(value)>
value тут std::optional<decltype(value)>
auto value = pObject.transform(Object::value);
Был пропосал на monadic optional и я до сих пор немного грущу что он не прошел в 20ый стандарт. У меня есть надежда, что его не приняли, так как думают его обобщить и на другие типы, возможно с добавлением сахара, но это исключительно мои влажные фантазии. Ну и могу добавить, что несложно написать свою реализацию в виде свободной функции. Читается хуже, но вполне работет.
NI
почитал про monadic optional
NI
хочу.
ГH
почитал про monadic optional
добавление optional было одной из двух ошибок в новом стандарте.
LA
auto value = pObject.transform(Object::value);
Был пропосал на monadic optional и я до сих пор немного грущу что он не прошел в 20ый стандарт. У меня есть надежда, что его не приняли, так как думают его обобщить и на другие типы, возможно с добавлением сахара, но это исключительно мои влажные фантазии. Ну и могу добавить, что несложно написать свою реализацию в виде свободной функции. Читается хуже, но вполне работет.
А что мешает написать монадик-опшионал? Я не знаю что это, но в C++ ведь монады пишутся
m
А что мешает написать монадик-опшионал? Я не знаю что это, но в C++ ведь монады пишутся
Монады сами по себе полезны, но эпизодически. Без сахара в виде do-нотации их часто не удобно использовать.
AD
добавление optional было одной из двух ошибок в новом стандарте.
и почему же?
ГH
и почему же?
Там выше написали же.
m
А что мешает написать монадик-опшионал? Я не знаю что это, но в C++ ведь монады пишутся
Monadic optional сильно ограничен и поэтому вполне юзабелен без сахара. Кажется там было всего 3 новых метода в
std::optional: transform (в девичестве fmap), then, else.LA
Монады сами по себе полезны, но эпизодически. Без сахара в виде do-нотации их часто не удобно использовать.
Ну, у нас появились корутины. Насколько я понимаю, они вполне заменяют некоторую часть do-нотации
ГH
а как должен себя вести
operator= для optional<T&>? rebind или assign through?Вот здесь главный вопрос об опшионале.
Имхо есть еще мина с misuse там, где должен быть expected/Either.
А второй ошибкой конечно был string_view.
Имхо есть еще мина с misuse там, где должен быть expected/Either.
А второй ошибкой конечно был string_view.
m
Ну, у нас появились корутины. Насколько я понимаю, они вполне заменяют некоторую часть do-нотации
Это интересные извращения (не поймите меня превратно, я люблю извращения), но в прод такое не стоит тянуть.
АК
Вот здесь главный вопрос об опшионале.
Имхо есть еще мина с misuse там, где должен быть expected/Either.
А второй ошибкой конечно был string_view.
Имхо есть еще мина с misuse там, где должен быть expected/Either.
А второй ошибкой конечно был string_view.
string_view может считаться ошибкой только в том случае, если их использует человек, не знающий ничего про лайфтаймы
LA
Это интересные извращения (не поймите меня превратно, я люблю извращения), но в прод такое не стоит тянуть.
Мне тоже нравятся извращения, будем знакомы... Но я вас понял :)
ГH
string_view может считаться ошибкой только в том случае, если их использует человек, не знающий ничего про лайфтаймы
бесполезно же