Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127442 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 19D911A00BC for ; Sat, 24 May 2025 15:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1748101249; bh=j7PgAMgiHWHf9FT0GeqkZZOV2ZFzg/aM9CJ6obFefdQ=; h=From:Date:Subject:To:From; b=HHxxsZgFfP1nfldAo1+G9NAD5RgfbWwLra3tb/W5pOhrQarRMtD95+F3K7Nr6C9LO rrLfnimEdpww3aWxoZCAJP71Fi1fIOVfNnLmxP9WmvH47OLXgUoESmbs5UzDTqgVA/ eaStu0UfuZ2xWMCn45c0EJDCkv+H++/W6iOzjmDP/qYUQa0yVyYdSJDZOFLg/5CNEP 77ZXGSx5ElBBkFBjw9gSxnzMNMbHoIUUJQkbVE+FbuQyYWOPVjO2XplHZGixFzsnGc iMBMbrd4ccsXpIE8ndRCKiLdztrfP3FUmdygFySSFb8Vix4lW4YPCqf6XBeuMDXumS gMCdTL4182isg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2F0FB18005D for ; Sat, 24 May 2025 15:40:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 24 May 2025 15:40:47 +0000 (UTC) Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-acacb8743a7so150264866b.1 for ; Sat, 24 May 2025 08:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748101374; x=1748706174; darn=lists.php.net; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=NvTuDMdi2npq496MI1USWYGcwG+i38GR/DyLkN4M/EY=; b=BHOIIY5wSlkSbJw0gFAI30Z3Zv6PKe3PxDRkkfXb41Q9wXuuM1dHJaQzEJfx8pZu4f na6zkdE3i0m9QeyRQDYs+v9ewhDPlFbNbLdCz11RKDlfEhjZanDrY74npACXai48yOGQ mb2f1psuslFB9+RhxX5sWv76EFoZwpQvIlJ3oFQPb/U3qLJj/5UkGPLy+BO0Rnw+yO73 WopL41cf4mcpFMyWl5jwLPzSPcKBT8I3gYKSIxC59LPbNPb3784mvwByqiQVEn5N4nTM 5Lo0T6TAQ8gpkriQV/PcF4gq0fGOozERESCiD/3lb/xyo2yq5zyYl4LgpKIFewhfOBMn qTEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748101374; x=1748706174; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=NvTuDMdi2npq496MI1USWYGcwG+i38GR/DyLkN4M/EY=; b=O8utKKmOcXd+eIU+LS/T9AAshIf2obvpc5I0dniaRaDOO+s2GE04Y2GwrCBpEuopZ1 U6iqu4geiD+ktNA7IV8aG0OhnhhTqCRlCDO7BoFTOA0L1RpGj5qgvlvx8AR29kYSqObi hhLvK52UZMSmeYVoFAtM+LP0Iyk97ibkb7o979tonVOuxE+oJC/slONu0MkhmJuEb8Sm lfQR51gMBJJ2D57RxiJT0RtmBS3ie9aZXvqQcpAel1HTgzmjAm7H72KFYd6p0Bpd36Ue 9d2MSFBsfz5BO0wKvbj9c8rUhU8kd3+zh1T3EQPRFMJNX+XwDwJcFHDUTd3t0zZdYDZH ODVg== X-Gm-Message-State: AOJu0YzCr1mtUXRGRi18Ikw01CtiVCa4m/6VSq8b19YDZsFJIy5ydaGD mx4ysLutfBidV/dDIknONUnb8+vIYZi7EuIOU+8y+r/dvCupuUHbyYWGzmGfJyy+CsYQrGDyyZf 7q9GPeZnnRA2yJcYlhWA88WFw1QDfeT3EITf2 X-Gm-Gg: ASbGncvEhTQKyQjQ/27RdJGvArRRBqTV7+T9l0R+f7bRBdNAYrGmJ3aTOO5JqtnJ9hj T2iErM5bYrVpD6yS2d7lajq+0kEuIqGFIEctT2Yr+XTVUGpFseDZjg0G5Ze/OOHAxE17U3d/fPr fBUzlmr+WoJ/73bAwKIWNOh2u/JXqH2aaRUA== X-Google-Smtp-Source: AGHT+IG/1MlypcETFgVMpajyYmugqHffOjQEW6On8FLVKzsJyr65wSWd3VDfLBvlg5ym1rGXIOKt7NrAN6eGn0FHrbo= X-Received: by 2002:a17:907:3f9c:b0:ad5:d6b3:5cd5 with SMTP id a640c23a62f3a-ad8596d9843mr325721166b.5.1748101373765; Sat, 24 May 2025 08:42:53 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Sat, 24 May 2025 23:43:17 +0800 X-Gm-Features: AX0GCFuzKpTRwxCipsni3KM2bDv2jiTrSzriTSPmhYbkRfMIv2LV7YEQfr1FZpg Message-ID: Subject: [PHP-DEV] [RFC] Add preserve_key_types to array_keys() to prevent unintended int conversion To: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000006a2ab60635e3917e" From: a766650827@gmail.com (=?UTF-8?B?6ams5q2j5by6?=) --0000000000006a2ab60635e3917e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi internals, I propose adding a preserve_key_types parameter to array_keys() to address issues caused by automatic conversion of string-numeric keys to integers. Developer Experience Considerations While PHP's automatic conversion of numeric string keys to integers is documented behavior, real-world usage shows this feature continues to cause unexpected issues: Cognitive Burden As observed in a Reddit discussion: "We understand the type coercion rules, but when converting '123' to 123 still catches us off guard when debugging some problems." As we mentioned earlier, the array_keys methodProduction Risks The implicit conversion creates hidden pitfalls: php =E5=A4=8D=E5=88=B6 // Cache system failure example$cache =3D ["123" =3D> "data"]; // Redis expects string keys$keys =3D array_keys($cache); // Returns [123] (int)$redis->get($keys[0]); // Fails silently Debugging Costs Issues manifest only at runtime, requiring: - Additional type validation code - Defensive programming with array_map('strval', ...) - Increased bug investigation time Problem ExamplesDatabase Performance Issues php $orderIds =3D ["1001", "1002"]; // VARCHAR keys in database$keys =3D array_keys($orderIds); // [1001, 1002] (unexpected int)$db->query("SELECT * FROM orders WHERE id IN (".implode(',',$keys).")"); =E2=86=92 May cause full table scans when VARCHAR indexes are ignored. Redis Cache Failures php $cacheData =3D ["user:1001" =3D> "data", "user:1002" =3D> "data"];$keys =3D array_keys($cacheData); // ["user:1001", "user:1002"] (correct)$numericData =3D ["1001" =3D> "data", "1002" =3D> "data"]; $numericKeys =3D array_keys($numericData); // [1001, 1002] (converted to int)$redis->mget(array_merge($keys, $numericKeys)); // Partial failure =E2=86=92 Mixed key types cause silent cache misses. Proposal Add a 4th parameter: php array_keys( array $array, mixed $search_value =3D null, bool $strict =3D false, bool $preserve_key_types =3D false ): array When true, maintains original key types. Questions for Discussion 1. Design Considerations - Should we provide a way to opt-out of this automatic conversion? - Would a new parameter be preferable to a separate function (e.g. array_keys_preserve())? 2. Use Case Validation - Are the database and Redis examples sufficient to justify this change? - Are there other common use cases we should consider? 3. Implementation Considerations - Should we consider making this the default behavior in a future major version? - Are there performance implications we should evaluate? Looking forward to your feedback. Best regards, [xiaoma] --0000000000006a2ab60635e3917e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi int= ernals,

I propose ad= ding a=C2=A0= preserve_key_types=C2=A0parameter to=C2=A0array_keys()=C2=A0to address issu= es caused by automatic conversion of string-numeric keys to integers.

Developer Experience Considerations

While PHP's automatic = conversion of numeric string keys to integers is documented behavior, real-= world usage shows this feature continues to cause unexpected issues:

Cognitive Burden

As observed in a=C2=A0Reddi= t discussion:

"We understand the type coercion= rules, but when converting '123' to 123 still catches us off guard= when debugging some problems."

As we mentioned earlier, the array_keys method

Production Risks

The implicit conversion creates hidden pitfalls:

php
=E5=A4=8D=E5=
=88=B6
<=
/div>
// Cache system failure examp=
le
$cache =3D ["123" =
=3D> "data"];  // Redis=
 expects string keys
$keys =3D array_keys($cache);  /=
/ Returns [123] (int)
$redis->get($keys[0]);  =
     // Fails silently

Debugging Costs

Issues manifest only at runtime, requiring:

  • Additi= onal type validation code
  • Defensive programming with=C2=A0array_map('str= val', ...)
  • Increased bug investigation time
Problem Examples

Database Performance Issues

php<=
/span>


$orderId=
s =3D ["1001", "=
1002"]; // VARCHAR keys in database
$keys =3D array_keys($orderIds); // [1001, 1002] (unexpected int)
$db->query("SELECT * FROM orders WHERE id IN (&quo=
t;.implode(',',$keys).")");

=E2=86=92 May cause full table scans when VARCHAR = indexes are ignored.

Redis Cache Failure= s

php

=

$cacheData =3D ["user:1001" =3D> "data&quo=
t;, "user:1002" =3D> "data"];
$keys =3D array_keys($cacheData); $numericData =3D ["1001" =3D> "data", "=
1002" =3D> "data"];=20
$numericKeys =3D array_keys($numericData); // [1001, 1002] (converted to int)
$redis->mget(array_merge=
($keys, $numericKeys=
)); // Partial failure

=E2=86=92 Mixed key types c= ause silent cache misses.

Proposal

Add a 4th parameter:

php
<=
div class=3D"gmail-hyc-common-markdown__code__langComponent expand" style=
=3D"margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inher=
it;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:i=
nherit;font-size-adjust:inherit;font-kerning:inherit;font-feature-settings:=
inherit;vertical-align:baseline;display:inline-flex">
=
array_keys(
    array $array,
    mixed $search_value =3D=
 null,
    bool $strict =3D false,
    bool $preserve_key_types =3D false
): array

When=C2=A0true, maintains original key types.

Questions for Discussion

  1. Design C= onsiderations

    • Should we provide a way to opt-out = of this automatic conversion?
    • Would a new parameter be preferable = to a separate function (e.g.=C2=A0array_keys_preserve())?

  2. Us= e Case Validation

    • Are the database and Redis exam= ples sufficient to justify this change?
    • Are there other common use= cases we should consider?

  3. Implementation Considerations

    • Should we consider making this the default behavio= r in a future major version?
    • Are there performance implications we= should evaluate?

Looking forward to your feedback.

Best regards,
[xiaoma]

--0000000000006a2ab60635e3917e--