mclow.lists 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); + ---------------- 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 ================ Comment at: include/string:1646 + class _Allocator = allocator<_CharT>, + class = typename enable_if<__is_allocator<_Allocator>::value, void>::type + > ---------------- 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`. https://reviews.llvm.org/D48616 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
