From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 49e243c0c85: Avoid resizing mutation in subst-char-in-string, take two Date: Tue, 14 May 2024 14:35:01 +0300 Message-ID: <86eda4wrru.fsf@gnu.org> References: <865xvhy4wn.fsf@gnu.org> <8AF4F364-9030-4634-91C5-79E297E5335B@gmail.com> <861q65x6yp.fsf@gnu.org> <718E190B-3C90-4304-87D8-69E82A1C7AC9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2838"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 14 13:36:30 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s6qSL-0000Oa-0k for ged-emacs-devel@m.gmane-mx.org; Tue, 14 May 2024 13:36:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6qRP-0007Fc-TQ; Tue, 14 May 2024 07:35:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6qRJ-0007Db-Po for emacs-devel@gnu.org; Tue, 14 May 2024 07:35:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6qRE-0004Vs-7O; Tue, 14 May 2024 07:35:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=EmfzIverDq4eZZBhtziAkIugoa643gmw35mEYWAo81k=; b=JIwNAoRYAiZMGQWMB5r8 MspTlCVP7SFt/r+PDz7xYGyISyrUB5az9nxXqHA9pYCrodNBclRuVc+jolut43h0aXAquS3LmR8hS bfVZE28LtyH+eyDWXOawWp/GOVjPEiSpBYq5aXDQx9aeyAbI5oXnLRqDeJ8Oht1mdbtjYEXx5n79p 37tNklC2RK4mUpbWjNkeJiG/MID7+WW5zrd1nepgCbVm6cduV6GvdLw8mrSCSMx8UFwXMfyP04+x4 q0ozgjsqPPdm5g8KXHNGJmyrgTexx9ELAIBRbesXRnN7Lq4Nq24WVX4ePDSARvAEZtXhHCS1mEirz qoWcPE7+7PYCRQ==; In-Reply-To: <718E190B-3C90-4304-87D8-69E82A1C7AC9@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Tue, 14 May 2024 12:44:34 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319221 Archived-At: > From: Mattias Engdegård > Date: Tue, 14 May 2024 12:44:34 +0200 > Cc: emacs-devel@gnu.org > > But it's not only a useful approximation but quite a defensible one: we do users no service at all if we let internal representation details leak out to the interface. It's much easier for us to describe, and for users to understand and follow, rules based on ASCII vs non-ASCII, for example, than "this character must use the same internal number of bytes as that one". I see no problem to document that in-pace replacement is possible only if it doesn't resize the original string. That leaks no implementation-specific information. And if someone is uncertain, the way to test this is very simple. > Simplicity as in describing and understanding it. The benefit from using the character size in bytes criterion is nil in practice. It will cease to be nil when and if we actually prohibit resizing (which is still the long-term goal, isn't it?). > As a matter of fact `string-replace` is likely to be faster than `subst-char-in-string` for most uses, sometimes radically so, I'd love to see numbers to go with this. However, the issue here is not just speed, it's also the support for in-place replacements.