Re: (aset UNIBYTE-STRING MULTIBYTE-CHAR)

[Kenichi Handa]

In article <address@hidden>, Stefan Monnier <address@hidden> writes:

> > Something like this code:
> >          (setq result (cons 
> >                        (let ((str (make-string 1 0)))
> >                          (aset str 0 (make-char 'japanese-jisx0208 ku ten))

> That's truly horrendous code.  I see no reason to support it.

> > although it's easy to fix it...

> Not only it's easy but the result is more efficient/legible/maintainable.

Even if the code is very bad, it worked in Emacs 22.  If
it doesn't work in Emacs 23, it's a regression.

>>> aset on strings is fundamentally problematic, so anything that restricts
>>> it further is good in my book (my own local Emacs disallows them
>>> plainly, and I rarely bump into code that needs it).

> > What is the fundamental problem?

> The one you're bumping into: multibyte strings are not arrays and
> treating them like ones asks for trouble: the performance is not the one
> expected, the implementation is complex and ugly, ...

The problem here is that (make-string 1 ?a) is a unibyte
string, but "a" generated by buffer-substring on a multibyte
buffer is a multibyte string.  The result of concatinating
them is also multibyte.  So, the multibyteness of strings is
difficult of expect.  If we are going to inhibit aset on
multibyte strings, I think we should inhibit aset on any
strings to avoid a further confusion.

> When weighed against the *very* rare cases where aset is used (let
> alone the even more rare cases where aset is actually useful and
> convenient), the choice is trivial (for me anyway).

Then, shouldn't we start the experiment of inhibitting aset
on strings just now?

---
Kenichi Handa
address@hidden