Объект (возможно, не С++ 14, возможно, библиотека TS) make_optional определен (в n3672) как:
template <class T>
constexpr optional<typename decay<T>::type> make_optional(T&& v) {
return optional<typename decay<T>::type>(std::forward<T>(v));
}
Почему необходимо преобразовать тип T (т.е. не просто возвращать optional<T>), и существует ли философское (а также практическое) обоснование использования decay в частности как преобразование?
Общая цель decay - взять тип и изменить его, чтобы он был подходящим для хранения.
Взгляните на эти примеры, что decay выполняет работу, а remove_reference не будет:
auto foo( std::string const& s ) {
if (global_condition)
return make_optional( s );
else
return {};
}
или
void function() { std::cout << "hello world!\n"; }
auto bar() { return std::make_optional( function ); }
или
int buff[15];
auto baz() { return std::make_optional( buff ); }
An optional<int[15]> был бы очень странным зверем - массивы стиля C плохо себя чувствуют, когда обрабатываются как литералы, что optional делает с его параметром T.
Если вы делаете копию данных, природа источника const или volatile не имеет значения. И вы можете сделать только простую копию массивов и функций, разложив их на указатели (не отступая от std::array или подобных). (теоретически можно было бы работать, чтобы сделать работу optional<int[15]>, но было бы много дополнительных осложнений)
Итак, std::decay решает все эти проблемы и на самом деле не вызывает проблем, если вы позволяете make_optional выводить свой тип аргумента, а не передавать T буквально.
Если вы хотите передать T буквально, нет никаких оснований использовать make_optional в конце концов.
Это не новое поведение с make_optional; функции утилиты make_pair и make_tuple ведут себя одинаково. Для этого я вижу как минимум две причины:
Может быть нежелательно или невозможно создать экземпляр шаблона с нераскрытыми типами.
Если T - это тип функции, ну, вы просто не можете хранить функцию внутри класса, периода; но вы можете сохранить указатель на функцию (разложившийся тип).
Если T - тип массива: результирующий класс будет "дефектным", потому что он не может быть скопирован из-за того, что массивы не могут быть назначены для копирования. Для optional функция члена value_or не может быть скомпилирована вообще, потому что она возвращает T. Следовательно, вы не можете иметь тип массива в optional вообще.
Неразлагающиеся типы могут привести к неожиданному поведению.
Если аргумент является строковым литералом, я лично ожидал, что тип будет const char*, а не const char [n]. Этот распад происходит в большинстве мест, так почему бы и нет здесь?
Если v является lvalue, тогда T будет выводиться как ссылочный тип lvalue. Действительно ли я хочу пару, содержащую ссылку, например, только потому, что один из аргументов был lvalue? Наверняка нет.
Тип внутри пары или кортежа или необязательный или что-то другое не должно приобретать cv-квалификацию v. То есть, скажем, x объявлен как const int. Должен ли make_optional(x) создать optional<const int>? Нет, не должно; он должен создать optional<int>.
Просто посмотрите, что делает decay:
Удаляет контрольные квалификаторы - T& → T; нет дополнительных ссылок, иначе вы не смогли бы переустановить optional, который должен быть назначен.
Для типов массивов удаляет экстент - T[42] → T*; необязательные массивы с фиксированной степенью сложности, которые полезны, потому что каждый размер массива имеет другой тип, и вы не можете напрямую передавать типы массивов по значению, необходимые для работы функций-членов value и value_or.
Для типов функций добавляет указатель- T(U) → T(*)(U); без дополнительных ссылок на функции по тем же причинам.
В противном случае удаляются cv-qualifiers- const int → int; нет дополнительных const значений, опять же, иначе вы не смогли бы переустановить optional.