Wow, some mixup --- Daniel, David, Devin and Levin. :-)

  Levin> There is no clear notion of an "Element" in a String.

  Daniel> If this is true, then we have a serious problem.  Before
  Daniel> doing much anything about its API, we need to decide whether
  Daniel> String is a byte array or a character array.  (Presumably,
  Daniel> matz & co. already have.)

  Black> My understanding was that the conceptual and design decision
  Black> was that Strings are not arrays, and are therefore not
  Black> obliged or constrained to have an Array-like API (any more
  Black> than arrays are obliged to have a String-like API).

To me, the term _array_ means ``sequence of elements stored in a
contiguous chunk of memory,'' just like the term _list_ means
``sequence of elements stored in a linked list of cells.''

As long as strings are implemented as arrays, I reserve the right to
refer to them as such, regardless of whether String < Array.
(Of course, I won't do it needlessly since it is confusing.)

In Haskell, strings are not arrays, but lists.  In many languages,
strings are immutable, which deemphasises their nature as arrays.
In Ruby, however, strings are mutable arrays (of bytes?).  So far I
have not been able to understand the desire to obfuscate this fact.

What's the harm of admitting that strings are arrays?  What's the harm
of making them at least _quack_ alike?

  Devin> Since the String methods don't have a consistent notion of an
  Devin> "element," it doesn't seem it would hurt to choose whichever
  Devin> notion we want for a potential #shift method.

  Black> That's true only if there's an imperative to have a String
  Black> instance method called "shift".  I don't think there is.

Why not?  This thread started with an example of the need for one.
Of course you can use string.slice!(0), but the same goes for arrays.

The terms `shift' and `unshift' are general and well-understood.
I can't see any reason why they shouldn't be applied to strings.

  Black> Maybe a left chop/chomp operation would be a good idea, but I
  Black> think it should be called lchop, which would be consistent
  Black> with other string method naming (rather than with array
  Black> method naming).

I fail to see the point in that.  String#chop is meant to chop off
end-of-line characters; String#lchop wouldn't be.  So using that name
would be _inconsistent_ with other string method naming.

-- 
Daniel Brockman <daniel / brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this?   --TTN.