------=_Part_138_28962590.1393016289312
Content-Type: text/plain; charset=UTF-8

I just stumbled upon N3921 and the mention that pop_front() and pop_back()already refer to heavier operations in the standard, resulting in
remove_prefix() and remove_suffix() instead.  That made me think about what
the operation is actually doing, which is essentially the same as
std::advance():  It is not mutating a container, but an iterator.

Would it perhaps thus be clear to call these functions advance_front(*n*)and
advance_back(*n*)?

Of course, advance_back() would be the reverse of remove_suffix(), as you'd
need to use a negative value to remove a suffix.  But perhaps that would be
more clear anyway?  It also makes it natural to move the front or back
iterators in either direction, more fully capturing the concept a view as a
sliding (and resizable) window.

(Side note:  I hope this is an appropriate place for this suggestion; I'm
just now dipping my first toe into the water of dialogue that's been going
on for decades.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_138_28962590.1393016289312
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I just stumbled upon N3921 and the mention that <span styl=
e=3D"font-family: courier new,monospace;">pop_front()</span> and <span styl=
e=3D"font-family: courier new,monospace;">pop_back()</span> already refer t=
o heavier operations in the standard, resulting in <span style=3D"font-fami=
ly: courier new,monospace;">remove_prefix()</span> and <span style=3D"font-=
family: courier new,monospace;">remove_suffix()</span> instead.&nbsp; That =
made me think about what the operation is actually doing, which is essentia=
lly the same as std::advance():&nbsp; It is not mutating a container, but a=
n iterator.<br><br>Would it perhaps thus be clear to call these functions <=
span style=3D"font-family: courier new,monospace;">advance_front(<i>n</i>)<=
/span> and <span style=3D"font-family: courier new,monospace;">advance_back=
(<i>n</i>)</span>?<br><br>Of course, <span style=3D"font-family: courier ne=
w,monospace;">advance_back()</span> would be the reverse of <span style=3D"=
font-family: courier new,monospace;">remove_suffix()</span>, as you'd need =
to use a negative value to remove a suffix.&nbsp; But perhaps that would be=
 more clear anyway?&nbsp; It also makes it natural to move the front or bac=
k iterators in either direction, more fully capturing the concept a view as=
 a sliding (and resizable) window.<br><br>(Side note:&nbsp; I hope this is =
an appropriate place for this suggestion; I'm just now dipping my first toe=
 into the water of dialogue that's been going on for decades.)<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_138_28962590.1393016289312--

.

It's a reasonable place for the discussion, although there's a fairly
pretty high bar to get the names changed since they've already been
discussed.

Eric's been working on a range proposal, and if there's some
consistent name for these operations, that would be a strong argument
to change string_view's names to match.

On Fri, Feb 21, 2014 at 12:58 PM,  <againey@gmail.com> wrote:
> I just stumbled upon N3921 and the mention that pop_front() and pop_back()
> already refer to heavier operations in the standard, resulting in
> remove_prefix() and remove_suffix() instead.  That made me think about what
> the operation is actually doing, which is essentially the same as
> std::advance():  It is not mutating a container, but an iterator.
>
> Would it perhaps thus be clear to call these functions advance_front(n) and
> advance_back(n)?
>
> Of course, advance_back() would be the reverse of remove_suffix(), as you'd
> need to use a negative value to remove a suffix.  But perhaps that would be
> more clear anyway?  It also makes it natural to move the front or back
> iterators in either direction, more fully capturing the concept a view as a
> sliding (and resizable) window.
>
> (Side note:  I hope this is an appropriate place for this suggestion; I'm
> just now dipping my first toe into the water of dialogue that's been going
> on for decades.)
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-02-21 15:58, againey@gmail.com wrote:
> Of course, advance_back() would be the reverse of remove_suffix(), as you'd
> need to use a negative value to remove a suffix.

....recede_back? If the above is an issue, I suspect there are possible
names that would sufficiently imply that the 'end' is moving closer to
the 'begin' (given a positive value).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Em sex 21 fev 2014, =E0s 17:01:45, Matthew Woehlke escreveu:
> On 2014-02-21 15:58, againey@gmail.com wrote:
> > Of course, advance_back() would be the reverse of remove_suffix(), as
> > you'd
> > need to use a negative value to remove a suffix.
>=20
> ...recede_back? If the above is an issue, I suspect there are possible
> names that would sufficiently imply that the 'end' is moving closer to
> the 'begin' (given a positive value).

chop()

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.