Сообщение Re[3]: Опциональные типы от 28.02.2017 1:27
Изменено 28.02.2017 1:29 antropolog
Re[3]: Опциональные типы
Здравствуйте, WolfHound, Вы писали:
WH>Теперь если у нас есть обобщённый код который работает с хештаблицей и в него передадут Hashtable<int, Option<string>> то без этой фичи код не будет знать есть элемент или в таблице лежит None.
WH>Из-за этого алгоритм может сломаться.
всё так, но только подобную семантику нужно выражать явно, а для этого просто нужен тип, который явно хранит информацию об ошибке, а-ля предлагаемого для C++std::expected<T, E>, и в случае ошибки строить логику вокруг этого самого E.
WH>Теперь если у нас есть обобщённый код который работает с хештаблицей и в него передадут Hashtable<int, Option<string>> то без этой фичи код не будет знать есть элемент или в таблице лежит None.
WH>Из-за этого алгоритм может сломаться.
всё так, но только подобную семантику нужно выражать явно, а для этого просто нужен тип, который явно хранит информацию об ошибке, а-ля предлагаемого для C++std::expected<T, E>, и в случае ошибки строить логику вокруг этого самого E.
Re[3]: Опциональные типы
Здравствуйте, WolfHound, Вы писали:
WH>Теперь если у нас есть обобщённый код который работает с хештаблицей и в него передадут Hashtable<int, Option<string>> то без этой фичи код не будет знать есть элемент или в таблице лежит None.
WH>Из-за этого алгоритм может сломаться.
всё так, но только подобную семантику нужно выражать явно, а для этого просто нужен тип, который явно хранит информацию об ошибке, а-ля предлагаемого для C++ std::expected, и в случае ошибки строить логику вокруг именно инстанса ошибки, а не вокруг нагруженного лишними смыслами optional
WH>Теперь если у нас есть обобщённый код который работает с хештаблицей и в него передадут Hashtable<int, Option<string>> то без этой фичи код не будет знать есть элемент или в таблице лежит None.
WH>Из-за этого алгоритм может сломаться.
всё так, но только подобную семантику нужно выражать явно, а для этого просто нужен тип, который явно хранит информацию об ошибке, а-ля предлагаемого для C++ std::expected, и в случае ошибки строить логику вокруг именно инстанса ошибки, а не вокруг нагруженного лишними смыслами optional