Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126071
Precedence: bulk
MIME-Version: 1.0
References: <CADPQA_QcJNMhd=KCM8Z0aVGm++on7_QE3D2DtTd+L36007qoqA@mail.gmail.com>
 <172D8C55-DCB2-4C5A-A224-C8B29B503DDF@gmail.com> <06e23630-16d0-4bbf-b49e-a04b43ff1f7b@gmx.de>
In-Reply-To: <06e23630-16d0-4bbf-b49e-a04b43ff1f7b@gmx.de>
Date: Wed, 27 Nov 2024 19:41:37 +0200
Message-ID: <CADPQA_TSN4E7mKKBMat+qccy0HLwp-aaj7xJ495XhvsWBcf4iw@mail.gmail.com>
Subject: Re: [PHP-DEV] Needs Feedback - Yield without value in reference
 generator function does not create notice
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Claude Pache <claude.pache@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f36b1f0627e87a92"
From: aggelosbellos7@gmail.com (aggelos bellos)

--000000000000f36b1f0627e87a92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> > A notice would be consistent with what happens with: `function &f() {
> return; }; f();`. But don=E2=80=99t add new notices in patch releases, ot=
herwise
> you may break without warning a non-trivial amount of code that conflates
> notices with fatal errors. The bug is not serious enough to warrant such =
a
> risk.
>

But isn't a bug that the notice is missing in the first place?


In my opinion, whether it should be deprecated is not a separate
> question, but the one we should answer first.  If we're not going to
> deprecate/remove the auto-conversion to a reference, we may as well drop
> the notice altogether, instead of adding a further notice.
>

Hmm I am not exactly sure if I agree with you. Whatever we decide, it will
happen in a new version. It feels right to fix the current supported
versions.
Regarding the deprecation decision, I checked the RFC
https://wiki.php.net/rfc/generators and I found this line:

*Only generators specifying the & modifier can be iterated by ref. If you
> try to iterate a non-ref generator by-ref an E_ERROR is thrown.*


Correct me if I am wrong, but this phrase refers to our case. If I
understand this correctly it should normally throw an E_ERROR so we should
continue perhaps with the deprecation? Other than this, I don't have a
strong opinion on if we should deprecate or not this case.

--000000000000f36b1f0627e87a92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; A n=
otice would be consistent with what happens with: `function &amp;f() { retu=
rn; }; f();`. But don=E2=80=99t add new notices in patch releases, otherwis=
e you may break without warning a non-trivial amount of code that conflates=
 notices with fatal errors. The bug is not serious enough to warrant such a=
 risk.<br></blockquote><div><br>But isn&#39;t a bug that the notice is miss=
ing in the first place?=C2=A0</div><div><br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">In my opinion, whether it should be=
 deprecated is not a separate<br>question, but the one we should answer fir=
st.=C2=A0 If we&#39;re not going to<br>deprecate/remove the auto-conversion=
 to a reference, we may as well drop<br>the notice altogether, instead of a=
dding a further notice.<br></blockquote><div><br></div><div>Hmm I am not ex=
actly sure if I agree with you. Whatever we decide, it will happen in a new=
 version. It feels right to fix the current supported versions.</div><div>R=
egarding the deprecation decision, I checked the RFC=C2=A0<a href=3D"https:=
//wiki.php.net/rfc/generators" target=3D"_blank">https://wiki.php.net/rfc/g=
enerators</a>=C2=A0and I found this line:</div><div><span style=3D"font-fam=
ily:arial,sans-serif;color:rgb(51,51,51)"><br></span></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><i><span style=3D"font-family:arial,sans-=
serif;color:rgb(51,51,51)">Only generators specifying the=C2=A0</span><code=
 style=3D"color:rgb(51,51,51);line-height:1.375rem">&amp;</code><span style=
=3D"font-family:arial,sans-serif;color:rgb(51,51,51)">=C2=A0modifier can be=
 iterated by ref. If you try to iterate a non-ref generator by-ref an=C2=A0=
</span><code style=3D"color:rgb(51,51,51);line-height:1.375rem">E_ERROR</co=
de><span style=3D"font-family:arial,sans-serif;color:rgb(51,51,51)">=C2=A0i=
s thrown.</span></i></blockquote><div><br></div><div>Correct me if I am wro=
ng, but this phrase refers to our case. If I understand this correctly it s=
hould normally throw an E_ERROR so we should continue perhaps with the depr=
ecation? Other than this, I don&#39;t have a strong opinion on if we should=
 deprecate or not this case.=C2=A0</div></div>

--000000000000f36b1f0627e87a92--