Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127532
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 02 Jun 2025 08:45:16 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <80c31a58-c3ca-4c39-92a6-4df479ac53ba@app.fastmail.com>
In-Reply-To: 
 <CAPZGkuNgtE538SFB0+gPUy_3Ne+95DpFcTUyj3x9TDhRKukdSg@mail.gmail.com>
References: 
 <CAPZGkuNkpX=drHENWCS-PuHKz0yWcOhZCmv0Y4Qnk5=DqcvakQ@mail.gmail.com>
 <c97acfab-03b7-4e8f-a62d-663150c119d5@daikaras.lt>
 <CAPZGkuMxxzA6-9LAjq51KxxOgvXNgz_X57zgB2FjokqKnFEfow@mail.gmail.com>
 <78B00771-EAA7-4191-8B34-C6FAA53B6B66@rwec.co.uk>
 <CAPZGkuNgtE538SFB0+gPUy_3Ne+95DpFcTUyj3x9TDhRKukdSg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Add preserve_key_types to array_keys() to prevent
 unintended int conversion
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 2, 2025, at 3:20 AM, =E9=A9=AC=E6=AD=A3=E5=BC=BA wrote:
> Hi Rowan, =20
>
> Thank you for the clear technical guidance. I agree we've reached a=20
> consensus that implementing a native Map type would be the proper=20
> solution to this long-standing issue. =20
>
> To move forward, I'd like to clarify a few practical aspects: =20
>
> 1. **RFC Proposal** =20
>    - Should I initiate an RFC draft at this stage? =20
>    - If yes, would you recommend starting with an "idea" thread on=20
> internals@lists.php.net first? =20
>
> 2. **Implementation Resources** =20
>    - Given my limited experience with PHP core development: =20
>      - What would be the minimal viable prototype to demonstrate=20
> feasibility? =20
>      - Are there active contributors you could refer who might be=20
> interested in collaborating? =20
>
> 3. **Interim Steps** =20
>    - Would it help to: =20
>      - Compile real-world use cases from major frameworks? =20
>      - Benchmark existing userland implementations (e.g., DS\Map)? =20
>
> I'm committed to driving this improvement and willing to coordinate=20
> non-code efforts. Your advice on the most effective next steps would b=
e=20
> invaluable. =20
>
> Best regards, =20
> [xiaoma]=20

There's been a fair amount of discussion in the past, and I am 100% in f=
avor of splitting list/sequence, set, and map types into separate types.=
  However, there's some challenges to doing so, mainly around, of course=
, type variance and generics.

See:
https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collecti=
ons/#full-reified-generics

(The "Collections" section, specifically, and the link to my research do=
cument.)

Gina is working hard on an associated types RFC ("generics junior"), whi=
ch would obviate the need for any custom syntax there.  That would actua=
lly allow doing *most* of the collection implementation in user-space; t=
he missing parts would be operators and being able to use more efficient=
 C implementations.  If Gina's RFC passes (it's not yet proposed, unfort=
unately), I intend to try and write user-space versions to flesh out the=
 design if nothing else.  Ideally I'd love for that to turn into an RFC =
in the future, but the bar for that is of course higher, and we'll have =
to see what else happens in the mean time.

I don't mean to dissuade you from looking into the topic; I just want yo=
u to be aware of the prior art so that we don't end up with multiple con=
flicting half-baked approaches instead of a single fully baked approach.

--Larry Garfield