Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123899 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 qa.php.net (Postfix) with ESMTPS id CD8481A009C for ; Wed, 26 Jun 2024 21:46:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719438467; bh=cYtMHN8u66xDXSrHbewmok1giQV+ypGJ2AYbJCSM/lE=; h=From:Subject:References:To:Date:From; b=lzjSS3aRgFsbWBkpwHpvFpBFVAv2MRglezqgF7qKXSmYlZSH+doAGy9HYbNQGsNNn ZMpGq5C6EiOdM9EfKHnn0+Hxau+NfHx5QLvZtP/uD/ACIXeMXCMI11Zrf5c4R1p/zt lZHi8k1tkt4iRuv6hEOp6uqDv3IL6RE7RWECxmcbfayLNMmQ3IUSP2a1diYtR+6GeM r8X0o4CnbekwS8yPJJwfrJki27qbb3iB3ReahqL01KPfDpT+ycEu4uN1aHAcxbyfS0 yx9WRYrRbJzwkwmSjqvZZvQX/tzqhkVmESll21a0zlXut9i/grrVB0XnG/w/gLTnvP UEAElTPMtR7QA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7F668180E52 for ; Wed, 26 Jun 2024 21:47:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) (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 ; Wed, 26 Jun 2024 21:47:44 +0000 (UTC) Received: by mail-il1-f171.google.com with SMTP id e9e14a558f8ab-376012bcc33so29507255ab.2 for ; Wed, 26 Jun 2024 14:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miles.systems; s=google; t=1719438385; x=1720043185; darn=lists.php.net; h=date:to:references:message-id:subject:mime-version:from:from:to:cc :subject:date:message-id:reply-to; bh=KR0xPJ9M3S3YMNbXnyZ52oudYYqQEw8QaRPLKiPoJAM=; b=R/2vLawV6/fkpAF4TJdd6FL79WxARgqMIfZ/SK9kPVrhBsWcTiUMliT2n4euy8wUax aDtTFUgcFni6/3LFGVsVZlc4owIVFY6OLMsKT30PiFbHq3ON2lqRuvVCtQDrQztF7HpV XnueIrEHj/Icsahk4ApwBYsypY0LTZ95AyHkFVyFNjv97tsV5vRSWn1MTqx7YIfFePnw p9k8nfw81hJwhkp7jLr36Aoe6sjmuydgaurYkTavaDaZQFPAu/LwRr5bGi+4gyN9MWTl 55VR79KxI3gN+VDOzWnBkBHEd7NDYdmuIELXMZh2JNz6VwSMid4JlFgAnpVAu3L5DWcU A7aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719438385; x=1720043185; h=date:to:references:message-id:subject:mime-version:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KR0xPJ9M3S3YMNbXnyZ52oudYYqQEw8QaRPLKiPoJAM=; b=kVH3PscYg7x1QclTz0obV67bBe60MPQVqfL1McbXMpO943pAO3J0uBLMLzbGgD6Pp3 EUxv8JqKyCISTZX6npPnIf2e4UdKKlbIfjbJxNhR69vnkucq/kFJ5n7P5c0HLpSk/23K gVqOtv3yJas5Rqy/5HdWIDGQ8rEUwuDDyfarHX8MItopgl1gYXcROpmL8FsnVpWI1Vy3 WoS5Dypg7/CKcnZGUW4cCj4bxZLXZcWIVUPKXb6rAK5HgnOJLTWvJfYRS3z9uFVyQyr9 ep4Jpi9a2WBlFd+3XR1KVoXbVnbT+je6aRGNiyepL7eZrNyZVLv8YiMqJKyTgBbnU20r TIlQ== X-Gm-Message-State: AOJu0YxHTdwbqgSrYFN0NPqrDvjwUayu+NtL8wq//PeSK56n/JvVtS+Z fAt3zgYHk3OjCqtSsDfdbX9pFRQC1eP1g4KLOXC3mJW3NOeG799ywjpcVCI9kkjfd0xhhS3fayL g/G87o1jA4oXKsHhKC73+Sl2tT+t2an/qmUfzQXk1Sg2HZkEcyI37pOM1NK+uJQkOSEVTbugAAA vN2+KoZA9IthBXo5z7pejSFibwijF4+kbGQAJmr1tD X-Google-Smtp-Source: AGHT+IGONKCeKh+leXNVwolZXvMIqX58YOus28lDTOKaw8G5cJI/B0gcn/IQLZ/Em8tEKe8FzOKWfQ== X-Received: by 2002:a05:6e02:1a8f:b0:375:cdb4:cc1b with SMTP id e9e14a558f8ab-3763f6ce165mr143494895ab.24.1719438385114; Wed, 26 Jun 2024 14:46:25 -0700 (PDT) Received: from smtpclient.apple ([2601:283:4600:6770:1058:1c9c:6c8b:173a]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-379a5da693esm100905ab.45.2024.06.26.14.46.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2024 14:46:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_93DF3898-669B-492D-8333-EB9C42B59B77" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Fwd: [PHP-DEV] [Initial Feedback] Typed Arrays Message-ID: References: To: php internals Date: Wed, 26 Jun 2024 15:46:13 -0600 X-Mailer: Apple Mail (2.3774.600.62) From: richard@miles.systems (Richard Miles) --Apple-Mail=_93DF3898-669B-492D-8333-EB9C42B59B77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I actually do like the idea of Generics, but the more I think about it, = it's not the problem here. Everyone should absolutely catch up on Larry = Garfield=E2=80=99s Pattern Matching RFC. It could be the key for = generics (the is operator). The problem is making "array interfaces" a = thing. Larry said he probably wouldn=E2=80=99t add support in this = version for array types, but I think that=E2=80=99s a mistake. We should = define a direction for what we would pass to `new Array` . I love = Casper Lanemeijer=E2=80=99s syntax suggestion with some changes: interface iArrayA ['a' =3D> string ] interface iArrayB implements iArrayA ['b' =3D> string, 'c' =3D> ?string = ] $array =3D iArrayA [ =E2=80=98a=E2=80=99 =3D> =E2=80=98hello' ]; // reads the same as a typecast $array =3D (iArrayA) [ =E2=80=98a=E2=80=99 =3D> =E2=80=98hello' ]; // it=E2=80=99s essentially like a typecast, which should probably be = allowed. If the set of possible values needs to increase a typecast = would do it.=20 class A { public iArrayB $array =3D [=20 =E2=80=98a=E2=80=99 =3D> =E2=80=98hello=E2=80=99, =E2=80=98b=E2=80=99 =3D> =E2=80=98world' ];=20 } Best, Richard Miles > Begin forwarded message: >=20 > From: Bilge > Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays > Date: June 26, 2024 at 3:04:30=E2=80=AFPM MDT > To: internals@lists.php.net >=20 > On 26/06/2024 21:56, Casper Langemeijer wrote: >>> Generics or bust. >>=20 >> I do not understand the reasoning behind that. Is it because we = really want generics, but when the 95% use-case is solved we fear that = there would not be enough momentum to get that? I'd love to have = generics too, but a very simple array syntax would in my opinion still = add a lot of value, even if we already had generics. > It's not that there wouldn't be enough momentum; if anything, a = successful typed arrays PR could give rise to such momentum. If it were = possible to have typed arrays that were fully compatible with an = (imagined) generics specification then I would be all for it. The = problem is, how can we ever ensure compatibility with something that = doesn't exist? >=20 > It seems to me we either solve is problem properly (with generics) or = not at all. >=20 > Cheers, > Bilge >=20 --Apple-Mail=_93DF3898-669B-492D-8333-EB9C42B59B77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I = actually do like the idea of Generics, but the more I think about it, = it's not the problem here. Everyone should absolutely catch up on Larry = Garfield=E2=80=99s Pattern Matching RFC. It could be the key for = generics (the is operator). The problem is making "array interfaces" a = thing. Larry said he probably wouldn=E2=80=99t add support in this = version for array types, but I think that=E2=80=99s a mistake. We should = define a direction for what we would pass to `new Array<T>` . =  I love Casper Lanemeijer=E2=80=99s syntax suggestion with some = changes:


interface iArrayA ['a' = =3D> string ]
interface iArrayB implements iArrayA ['b' = =3D> string, 'c' =3D> ?string = ]


 $array =3D iArrayA = [
= =E2=80=98a=E2=80=99 =3D> = =E2=80=98hello'
];
// reads the same as a = typecast
 $array =3D (iArrayA) [
=E2=80=98a=E2= =80=99 =3D> =E2=80=98hello'
];

// = it=E2=80=99s essentially like a typecast, which should probably be = allowed. If the set of possible values needs to increase a typecast = would do it. 

class A {
  = public iArrayB $array =3D [ 
=E2=80=98a=E2=80=99 =3D>= =E2=80=98hello=E2=80=99,
=E2=80=98b=E2=80=99 =3D>= =E2=80=98world'
= ]; 
}

Best,
Richard Miles

Begin forwarded = message:

From: Bilge = <bilge@scriptfusion.com>
Subject: Re: [PHP-DEV] [Initial Feedback] Typed = Arrays
Date: June 26, = 2024 at 3:04:30=E2=80=AFPM MDT
To: internals@lists.php.net

On 26/06/2024 21:56, Casper Langemeijer = wrote:
 Generics or = bust.

I do not understand the = reasoning behind that. Is it because we really want generics, but when = the 95% use-case is solved we fear that there would not be enough = momentum to get that? I'd love to have generics too, but a very simple = array syntax would in my opinion still add a lot of value, even if we = already had generics.

It's not that there wouldn't be enough momentum; = if anything, a successful typed arrays PR could give rise to such = momentum. If it were possible to have typed arrays that were fully = compatible with an (imagined) generics specification then I would be all = for it. The problem is, how can we ever ensure compatibility with = something that doesn't exist?

It seems to me we either solve is problem = properly (with generics) or not at all.

Cheers,
Bilge


= --Apple-Mail=_93DF3898-669B-492D-8333-EB9C42B59B77--