Date: Sat, 9 Nov 2019 11:05:07 +0000
On Sat, Nov 9, 2019 at 3:44 AM Lyberta <lyberta_at_[hidden]> wrote:
> Lyberta:
> > JeanHeyd Meneide:
> >> Absolutely, the default should be basic_string.
> >
> > I disagree but I didn't write a proposal yet so we'll talk later.
>
> Although here's one of the big arguments why std::basic_string is really
> badly designed:
>
> http://www.gotw.ca/gotw/084.htm
>
> And then if we note that Unicode code units have almost zero semantics,
> we can remove 80% of the API.
>
As a counterpoint, there's no reason you can't just ignore the vestigal API
on std::string. While a "bloated" interface, long gone are the days where a
function you write has to appear in your final binary, or even in your
object files.
I understand it's not ideal, but remember that introducing new vocabulary
types means you need to compete with every single API that currently takes
std::string. That's a lot of APIs you're risking no compatibility with, and
explicit conversions means the user has a lot of typing to do. Try to think
about how expensive that can be for the user if you introduce new basic
types, and the compatibility you lose with code being written even today.
You can still propose such types, but please do be careful: it might not be
the best use of your time for something Library Evolution Working Group
(Incubator) will likely shoot down immediately.
Sincerely,
JeanHeyd
> Lyberta:
> > JeanHeyd Meneide:
> >> Absolutely, the default should be basic_string.
> >
> > I disagree but I didn't write a proposal yet so we'll talk later.
>
> Although here's one of the big arguments why std::basic_string is really
> badly designed:
>
> http://www.gotw.ca/gotw/084.htm
>
> And then if we note that Unicode code units have almost zero semantics,
> we can remove 80% of the API.
>
As a counterpoint, there's no reason you can't just ignore the vestigal API
on std::string. While a "bloated" interface, long gone are the days where a
function you write has to appear in your final binary, or even in your
object files.
I understand it's not ideal, but remember that introducing new vocabulary
types means you need to compete with every single API that currently takes
std::string. That's a lot of APIs you're risking no compatibility with, and
explicit conversions means the user has a lot of typing to do. Try to think
about how expensive that can be for the user if you introduce new basic
types, and the compatibility you lose with code being written even today.
You can still propose such types, but please do be careful: it might not be
the best use of your time for something Library Evolution Working Group
(Incubator) will likely shoot down immediately.
Sincerely,
JeanHeyd
Received on 2019-11-09 12:05:22