On the explicitness of it all

[Daniel]

Is there a reason why

explicit
basic_string(std::basic_string_view<CharT, Traits> sv,
const Allocator& alloc=Allocator()); // (1)

is explicit, but

operator std::basic_string_view<CharT, Traits>() const noexcept;

is not?

I can't see a particular reason for making (1) explicit, considering
that the constructor that takes const CharT* s is not.

Thanks,
Daniel

[Alf P. Steinbach]

I can't think of any reason either. It's weird. Checking `string_view`
paper...

Didn't find it there, but there was a thread in Google group "ISO C++ -
Standard Discussion", at <url:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/YVGIEJOt_E0%5B1-25%5D>.
Some people argued that one should make conversion to string less
convenient in order to encourage the opposite conversion, to foster more
use of `string_view`. And also an argument from efficiency, that it
should be discouraged because mumble mumble handwaiving efficiency. And,
hey, conversion to string can throw, and therefore conversion from char
const* would have been explicit if designed today.

I think it's all bollocks.


Cheers!,

- Alf

[Daniel]

On Thursday, February 15, 2018 at 1:46:10 AM UTC-5, Alf P. Steinbach wrote:
> On 14.02.2018 23:43, Daniel wrote:
> > Is there a reason why
> >
> > explicit
> > basic_string(std::basic_string_view<CharT, Traits> sv,
> > const Allocator& alloc=Allocator()); // (1)
> >
> > is explicit, but
> >
> > operator std::basic_string_view<CharT, Traits>() const noexcept;
> >
> > is not?
> >

> there was a thread in Google group "ISO C++ -
> Standard Discussion", at <url:
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/YVGIEJOt_E0%5B1-25%5D>.
> Some people argued that one should make conversion to string less
> convenient in order to encourage the opposite conversion, to foster more
> use of `string_view`. And also an argument from efficiency, that it
> should be discouraged because mumble mumble handwaiving efficiency. And,
> hey, conversion to string can throw, and therefore conversion from char
> const* would have been explicit if designed today.
>
> I think it's all bollocks.
>

Thanks Alf, I thought there must have been a technical safety reason, but
from that thread it appears not. I share your sentiments.

Daniel