Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121376
MIME-Version: 1.0
References: <CAJpLVh1P0kTneo+chFEdp2oCmSKNpgpDxSXd3atv9OHKejABgw@mail.gmail.com>
 <9d5388fa-a5a5-4fa5-81ff-16f6670f80b6@gmail.com>
In-Reply-To: <9d5388fa-a5a5-4fa5-81ff-16f6670f80b6@gmail.com>
Reply-To: autaut03@gmail.com
Date: Wed, 18 Oct 2023 14:01:49 +0300
Message-ID: <CABigaAULVVGhZCD7bvthZ1NsVc1s8LDsnTS-9=V=APGx=tjbfw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000096c3740607fb91a5"
Subject: Re: [PHP-DEV] Previous discussions about generics syntax only?
From: autaut03@gmail.com (Alex Wells)

--00000000000096c3740607fb91a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 17, 2023 at 10:40=E2=80=AFPM Rowan Tommins <rowan.collins@gmail=
.com>
wrote:

Using the same syntax for type information that is guaranteed to be true
> (existing run-time checks) and type information that is "advisory only"
> (new checks for optional static analysis) means users can no longer have
> confidence in that type information.


 If "syntax only" solution was temporary then warning users through some
kind of opt-in mechanism (like with strict_types=3D1) may be enough - that
way users will know that generics type information is "advisory only" and
that this might change in the future. In some other languages (Kotlin)
there are opt-in mechanism for experimental features - ones that are
possibly incomplete, unstable or non-final, and it's working quite well for
them.

On the other hand, I can see a "third way": if the problem with current
> static analysis conventions is that they have to be parsed out of a
> string-based docblock, we can provide *dedicated* syntax, without
> unifying it with the standard type syntax. For instance, some of the
> earlier discussions around introducing attributes suggested reflection
> expose the AST of the attributes arguments, rather than the resolved
> expressions, allowing them to act a bit like Rust's "hygienic macros".
> If that was added as an optional mode, you might be able to do something
> like this:
>

 The community has just now decided on the PHPDoc syntax for generics, has
just started widely adopting them in packages and has just got first-party
support from PHPStorm. I doubt that migrating to yet another temporary
solution (one that still doesn't address all of the concerns) is a good
idea right now.

--00000000000096c3740607fb91a5--