[PATCH] D48616: Implement LWG 2946, 3075 and 3076

[Louis Dionne via Phabricator via cfe-commits]

ldionne added inline comments.


================
Comment at: include/string:842
+        explicit basic_string(const _Tp& __t,
+                     typename enable_if<__can_be_converted_to_string_view<_CharT, _Traits, _Tp>::value, void>::type* = 0);
+
----------------
mclow.lists wrote:
> ldionne wrote:
> > Is there a reason why you use a different `enable_if` pattern here (as a default argument) and above (as a default template argument)?
> One for constructors, one for non-constructors.
> https://stackoverflow.com/questions/17842478/select-class-constructor-using-enable-if
Even after reading the SO question, I think the following would work as well?

```
template<class _Tp, class = typename enable_if<__can_be_converted_to_string_view<_CharT, _Traits, _Tp>::value, void>::type>
_LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
explicit basic_string(const _Tp& __t);
```

Again, I'm not suggesting any change, just trying to understand,


================
Comment at: include/string:1646
+         class _Allocator = allocator<_CharT>,
+         class = typename enable_if<__is_allocator<_Allocator>::value, void>::type
+         >
----------------
mclow.lists wrote:
> ldionne wrote:
> > You don't need to specify the `void` in `enable_if<__is_allocator, void>::type`. There's no harm in specifying it, but I'm curious to know if there's a reason for it?
> Habit, I guess - I always put the type into `enable_if`, even if I don't use it.  Sometimes I use `nullptr_t` instead of `void`.
Understood.


https://reviews.llvm.org/D48616