Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119306
Return-Path: <george.banyard@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 42342 invoked from network); 18 Jan 2023 12:23:03 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 18 Jan 2023 12:23:03 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id A04B51801FD
	for <internals@lists.php.net>; Wed, 18 Jan 2023 04:23:02 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,
	SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no
	version=3.4.2
X-Spam-ASN: AS15169 209.85.128.0/17
X-Spam-Virus: No
X-Envelope-From: <george.banyard@gmail.com>
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Wed, 18 Jan 2023 04:23:02 -0800 (PST)
Received: by mail-pj1-f51.google.com with SMTP id dw9so34177674pjb.5
        for <internals@lists.php.net>; Wed, 18 Jan 2023 04:23:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=SPIikwsgchxOjgeh/9GMtYW0j+5r6iOikhYyXiJDofs=;
        b=pCuaSteTBADxtbti4CNbODd7A9Dc1NvLTBxyMwGDesIyGfGI3vS86hMRPrJzoCEzkU
         7Yps4cLmJVSZki9wGz6qHxT9DStKDf+lw5EqCtmZm/ykmX3bVBIz1YmoPXb5Odfz2SxV
         kuQL+/+BYD7lhV2LVKL7soWx3453oP8GlDo1cjBG/92I6T2qfr8S3WO5fH8YcBxI2nXi
         ClAr5VJiCHg4UaYnYTudJWHEluoGU+/0r6RFDNNTNv0G0oKXEZLuYG+yh3as0G8BCCa3
         ZKz4ak3euFTT0LLW8bU/gXA+VgjWYb+pFTGH4/m9hT2+fDa06m/M/xDxgUR/wBC24Xyq
         tLiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SPIikwsgchxOjgeh/9GMtYW0j+5r6iOikhYyXiJDofs=;
        b=ccgNFbTFWJP7NpbGQY9+YixgR0Tsdfp1umaEUtc1lxL1salRoQKU7NLqLkg03sUDsx
         wQyQOgWeAs2tnofQXpn8yAiMY+cgetmbAKlGgVK9z4W70U6t7ecMGmvKFORUrxcTmLuA
         aoKX27e8zu5KCV1q1kXWixEVUPXoj4JdnXuLwh4nA8b1dOKpYrmaCC8PhFMicee2Nspf
         YTpeEIdI40nCCVQeMqa2Qhj8rk9DgswE25u4oICG9xEzpkPt2mDRhqoJI8+Xynztrtkj
         7b4qkxR/gR3ogYw8beyTDfgWN3VF8r92cCvibT8ior3AH4Me55/CEYH5gpkot3DavN0S
         dUew==
X-Gm-Message-State: AFqh2ko2DLScWwRqjvt9shAMN5bB5zMfNj2BlPy73K5rbrW+9IlOwxhk
	I33gXxgDxJzobCsI0Sue5LmPYkPYbwGKxbRURWZJC4EqyMg=
X-Google-Smtp-Source: AMrXdXsM9MAFrvEE8ZDjl6Z7PRvUWfQx+oOnOy9fSwLQDiyKBDCwh/Xl5U2L4HdsXjwsXJnpBp7yQfVPMr7lKP2qyZw=
X-Received: by 2002:a17:903:25c3:b0:194:457d:6dd6 with SMTP id
 jc3-20020a17090325c300b00194457d6dd6mr538864plb.15.1674044581250; Wed, 18 Jan
 2023 04:23:01 -0800 (PST)
MIME-Version: 1.0
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
 <5FC8DBAF-8D78-4E94-A3B0-3BDED3A3E53C@craigfrancis.co.uk> <789af205-4582-66a9-694a-10e18b8b9f56@demon-angel.eu>
In-Reply-To: <789af205-4582-66a9-694a-10e18b8b9f56@demon-angel.eu>
Date: Wed, 18 Jan 2023 12:22:50 +0000
Message-ID: <CAFPFaMLAnCqhPFZHQXnABbw=aXXj53DwtaDOf=+zQ4jN1Z+OmA@mail.gmail.com>
To: mark@demon-angel.eu
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000009a8ae405f288e0d0"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: george.banyard@gmail.com ("G. P. B.")

--0000000000009a8ae405f288e0d0
Content-Type: text/plain; charset="UTF-8"

On Tue, 17 Jan 2023 at 18:28, Mark Baker <mark@demon-angel.eu> wrote:

> On 17/01/2023 17:28, Craig Francis wrote:
> > I've seen this used a few times, e.g. starting with a numerical value
> (Passport number, NHS number, Social Security Number, Date of Birth
> 20230117), and the developer simply appends an incrementing letter on the
> end to get a unique reference; e.g. a person having multiple assessments...
> especially if it's more than 26 (A-Z), and you need to move to multiple
> letters, which `chr(90 + 1)` cannot help you with.
>
> Being able to increment alpha strings is incredibly useful when working
> with Excel spreadsheets (as I do on a daily basis), because the column
> Ids match this pattern; and I would hate to see this deprecated. Having
> to replicate that logic for traversing column Ids in userland code would
> be inconvenient (to say the least), would affect many of the users of my
> libraries, and would have a performance impact on my libraries. If
> anything, I'd rather like to see the decrement operator work with alpha
> strings as well for more consistency.
>
> I don't have the karma for a vote; but if I did then it would be a "No"
> for this alone, because I can see the problems that it will cause me and
> the users of my libraries.
>
>
> > That said, I appreciate that incrementing some strings can be a bit
> unusual (e.g. "A9" to "B0", vs "A 9" to "A 0").
>
> Agreed. While incrementing works in a very logical manner with mixed
> alphanumeric strings, it's not well documented behaviour, and most
> developers take a long time before they understand what it's actually
> doing. While there might be use cases for incrementing alphanumerics, I
> suspect that it would be better implemented in the business logic of an
> application, because the component parts of that string are likely to
> have business meaning; and also to provide better code readability.
>

I appreciate being shown concrete cases about the useful ness of this
operation.
The reason I didn't go with adding support for decrementing alphanumeric
strings is that it was unanimously rejected.
However, if Rowan's suggestion of adding
string_increment()/string_decrement() with more rigorous behaviour (that we
can flesh out together) would be part of this proposal, would you be more
inclined to accept deprecating ++ from performing this feature?

I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -=
1; is something to strive for *because* it allows us to remove one
dedicated type juggling context people need to be aware of and simplifies
the overall semantics of the language.
Keeping support for string increments means that one cannot interchange $v++
and $v += 1 and that one needs to be aware about using it when a value
might hold a string.
As such, if it needs to remain its own type juggling context, the question
is why not make it stricter by having it warn and then throw a TypeError on
bool, reopening the can of worms that is the null handling between both
operators and what to do with the empty string case.
These questions are already answered by making those operators behave just
like addition/subtraction.

My order of preference for the semantics are as follows:
1. The behaviour described in the RFC (with or without function for string
in/decrement)
2. (with a massive gap, but I could live with it) adding support for string
decrements and tiding up the behaviour of the alphanumeric string to make
it stricter and less error-prone.
3. The current asymmetry (again with a massive gap between this and option
2)

But because option 2 seems out of the question due to the unanimous
rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only
viable options to me seem like 1 and 3.
As I hate option 3 I am pushing for option 1 as I think it has various
benefits.

Moreover, I do not want to split this into its own proposal (deprecating
string increments/figuring out what to do with them) as I feel it will make
any attempt to improve the situation harder.

Best regards,

George P. Banyard

--0000000000009a8ae405f288e0d0--