Talk:cpp/utility/optional/optional

template < class U = T > /* EXPLICIT */ constexpr optional( U&& value );	(8)	(since C++17)

This doesn't make sense to me. Should it be template < class T = U >?

gubbins (talk) 02:15, 25 January 2017 (PST)

T is the template parameter of std::optional. --D41D8CD98F (talk) 02:40, 25 January 2017 (PST)

We could replace T with value_type (or even with std::optional<T>::value_type), but I guess that wouldn't make it clearer. --D41D8CD98F (talk) 02:42, 25 January 2017 (PST)

Why not just say template < class U >? I can't really see what the = T part adds except for confusion. It would be better to describe the behaviour in the full constructor descriptions - like constructor 3 for std::pair, for example. gubbins (talk) 13:42, 25 January 2017 (PST)

template < class U > would be wrong because it would be a rather different constructor. template <class U = T> EXPLICIT constexpr optional(U&& v); was added to the standard by LWG 2756 which describes its purpose. if you believe it is not useful.. https://isocpp.org/std/submit-issue --Cubbi (talk) 14:00, 25 January 2017 (PST)

A note may help, though. A more radical idea is a global stylistic change to say std::optional<T>::optional in the title instead (i.e., include the template parameters), so that it's clear what T is. T. Canens (talk) 19:16, 26 January 2017 (PST)

I agree with the remark above. The document you linked does not refer to template <class U = T> in isolation; it is within a declaration of template <class T> optional. So in that setting, the meaning of T is explicit. To readers of this page I do not think it is very clear that T is the template parameter of the optional template itself. gubbins (talk) 18:51, 2 March 2017 (PST)

How about template <class U = value_type> in this case? --Cubbi (talk) 19:44, 2 March 2017 (PST)

Yes I think template <class U = value_type> would be better than the current version - probably a good change for now. However I quite like the idea of using std::optional<T>::optional as the title - what do you think about that? gubbins (talk) 20:16, 2 March 2017 (PST)

it may get harder elsewhere.. std::unordered_map<Key,T,Hash,KeyEqual,Allocator>::unordered_map.. actually that might still fit in a title, though we might want to abbreviate "Allocator" for that. --Cubbi (talk) 05:29, 3 March 2017 (PST)

Yeah true, although std::unordered_map<Key,T,...>::unordered_map might work too? gubbins (talk) 20:28, 22 March 2017 (PDT)

I replaced T with value_type on the page - I think it's better... gubbins (talk) 20:28, 22 March 2017 (PDT)

explicit constructors

Why is explicit in a comment? It's not in a comment here: http://en.cppreference.com/w/cpp/container/vector/vector 2620:0:1000:8000:ACAE:4A00:D7A8:BA35 17:37, 12 February 2018 (PST)

here it is conditionally-explicit, the description below the declaration explains when it is and when it isn't. Perhaps we should use a different presentation, like (conditionally-explicit)--Cubbi (talk) 18:06, 12 February 2018 (PST)

I don't want to hide conditionally-explicit in the small print. But maybe we can make the meaning more obvious than the /* EXPLICIT */ we have so far. T. Canens (talk) 13:00, 14 February 2018 (PST)

The condition for the 7th ctor

I believe the condition for the 7th ctor should be std::is_constructible_v<T, std::initializer_list<U>&, Args...> (no double ampersand after Args), though I'm not sure.

2A02:6B8:0:40C:99CD:2BDB:50CA:440 08:41, 29 October 2018 (PDT)

The two are equivalent in this case, and the standard has the &&. T. Canens (talk) 13:23, 29 October 2018 (PDT)