Please start a new email thread when switching subjects; replying with a
new subject breaks thread presentation.

On 08/03/2018 06:55 PM, Lyberta wrote:
> So I'm reading p0224r2 again and found this line:
>
> using text_view = basic_text_view<execution_character_encoding,
> /* implementation-defined */ >;
>
> Is it really needed? C++17 added class template argument deduction and
> we can use deduction guides to properly instantiate what is now a
> basic_text_view. There are make_text_view helpers but I think they are
> not needed for most use cases. Consider:
>
> std::text_view tv{u8"Hello"};
>
> This should be what people write in their code, that would deduce UTF-8
> view assuming char8_t is in the standard and we use C++17 CTAD.

Replacing the make_text_view() factory functions with C++17 CTAD has
been on my todo list for a long time; yet another thing I just haven't
gotten to yet. I created a github issue to track it:
- https://github.com/tahonermann/text_view/issues/34

I think the type aliases are useful for non-deduced contexts. For
example, when declaring function parameters.

>
> More importantly, text_view having execution_character_encoding makes
> this encoding have more weight to it, especially for beginners. We all
> know that in practice working with execution character set is basically
> a nightmare, we shouldn't put in on a forefront of text processing.

I don't think it is feasible to avoid the execution character encoding
given that it is the encoding used for I/O. Eventually, we may be able
to add I/O interfaces that implicitly transcode at program boundaries,
but we don't have that yet. I think beginners should be able to write
hello world without having to (explicitly) deal with transcoding. For
many applications, the execution character encoding is the right
encoding to target.

Tom.