Date: Thu, 21 Mar 2024 16:03:03 +0100
This is true. What I'm suggesting is not anything major or ground-breaking.
I merely find *.substr()* to sometimes feel a bit cumbersome. It serves its
purpose and it works just fine.
My suggestion to add a *.slice()* (or *.subview()* or *.sliced()*) stems
from the fact that many other programming languages *also* get substrings
in the way of (*begin, end*) vs (*begin, size*). It is merely to offer an
extra alternative for people working with C++.
Does it introduce teachability problems?
Perhaps for beginners, yes. It might be hard to explain why *.sliced()* and
*.substr()* exist and seem to do nearly identical things, however, the same
argument can be made for *std::erase_if()* and the older
*std::vector::erase(std::remove_if())*. Functionally they do very similar
things, but it's a different syntax.
The comparison is not ideal, since *std::erase_if()* also shortens the
syntax, but it still has the same teachability problem of having multiple
options to do the same thing.
I think it is nice for programmers coming from other languages to have
methods for string manipulation that more closely mimic the ones from the
language they come from (Python & Rust for example).
My main concern for this could indeed stem from *operator[](size_t begin,
size_t end)* since that could be confusing for a multitude of reasons, but
overall, and upon everyone's arguments it indeed does seem like something
that should be more thought out over time.
However, I do not think that *.sliced()* comes with such caveats of being
confusing to users.
The functions have a different name, but serve similar utility purposes,
which is then left up to the programmer in question to use whatever fits
best for their needs and preferences.
I'll soon update the proposal to remove the multi-indexed *operator[]*,
*first()* and *last()* (I'll make a new proposal for *first()* and *last()*
).
I do continue to see merit in a *sliced()* function being added to the STL,
but indeed, there is not much reason besides enhancing the enjoyment of
using the *std::string* api in general and improving it even more.
I merely find *.substr()* to sometimes feel a bit cumbersome. It serves its
purpose and it works just fine.
My suggestion to add a *.slice()* (or *.subview()* or *.sliced()*) stems
from the fact that many other programming languages *also* get substrings
in the way of (*begin, end*) vs (*begin, size*). It is merely to offer an
extra alternative for people working with C++.
Does it introduce teachability problems?
Perhaps for beginners, yes. It might be hard to explain why *.sliced()* and
*.substr()* exist and seem to do nearly identical things, however, the same
argument can be made for *std::erase_if()* and the older
*std::vector::erase(std::remove_if())*. Functionally they do very similar
things, but it's a different syntax.
The comparison is not ideal, since *std::erase_if()* also shortens the
syntax, but it still has the same teachability problem of having multiple
options to do the same thing.
I think it is nice for programmers coming from other languages to have
methods for string manipulation that more closely mimic the ones from the
language they come from (Python & Rust for example).
My main concern for this could indeed stem from *operator[](size_t begin,
size_t end)* since that could be confusing for a multitude of reasons, but
overall, and upon everyone's arguments it indeed does seem like something
that should be more thought out over time.
However, I do not think that *.sliced()* comes with such caveats of being
confusing to users.
The functions have a different name, but serve similar utility purposes,
which is then left up to the programmer in question to use whatever fits
best for their needs and preferences.
I'll soon update the proposal to remove the multi-indexed *operator[]*,
*first()* and *last()* (I'll make a new proposal for *first()* and *last()*
).
I do continue to see merit in a *sliced()* function being added to the STL,
but indeed, there is not much reason besides enhancing the enjoyment of
using the *std::string* api in general and improving it even more.
-- Rhidian De Wit Software Engineer - Barco Op di 19 mrt 2024 om 21:27 schreef Jonathan Wakely via Std-Proposals < std-proposals_at_[hidden]>: > On Tue, 19 Mar 2024 at 17:57, Breno Guimarães via Std-Proposals > <std-proposals_at_[hidden]> wrote: > > > > For what it's worth, I strongly disagree with "s[i, j] seems actively > bad". I think the level of confusion with this syntax will be minimal. I > would be very surprised if developers try to "multi-index" into a string > (which doesn't even make sense) and are surprised that it doesn't work. > > > > Several operations in C++ have the same syntax and slightly different > meanings. And several operations have drastically different meaning (like > operator * and multiplication). > > Another example is operator/ for std::filesystem::path. I don't recall > seeing angry developers complaining that / is not dividing their path but > appending. > > It's all about the context. > > But operator/ only means *one* thing for a filesystem::path. > > Barry's point is that for a multi-dimensional array we might want > multi-indexing into it, and we might also want to support taking a > slice of it. If x[i,j] means multi-indexing for some types, and > slicing for other types, what does it mean for types that support both > multi-indexing and slicing? > -- > Std-Proposals mailing list > Std-Proposals_at_[hidden] > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals > -- Rhidian De Wit Software Engineer - Barco
Received on 2024-03-21 15:03:17