If it is, you can set the XDEBUG_MODE environment variable to off, and then it
doesn't set any hooks that could interfere.
cheers
Derick
uot;
>
>What is the correct procedure for this ?
>
>Thanks
Make a PR against
<https://github.com/php/web-php/tree/master/include/download-instructions> /
<https://github.com/php/web-php/blob/master/downloads-get-instructions.php> /
<https://github.com/php/web-php/blob/master/downloads.php>
cheers
Derick
equesting a review from @release-managers
cheers
Derick
Hi,
Can you please not top-reply on this list? It's on our guidelines.
wiki page itself too. Some of them
already include version numbers with changes made in these[1], and that
would be an excellent point as to where to add this.
[1] https://wiki.php.net/rfc/domdocument_html5_parser#changelog
cheers,
Derick
.h:PHP_MINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_MSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_RINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_RSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_MINFO_FUNCTION(mb_regex);
makes it feel that it already sort-of operates as a sub-extension, and
it wouldn't be *too* m
tter to set up a page at php.net/pie to link folks
>to, and this page can link to the repository.
>
>Cheers,
>Ben
Ideally we have a page in the docs like this,
<https://www.php.net/manual/en/install.composer.intro.php>, for which we then
can setup a short url (which we should also do for /composer).
Happy to help with this.
cheers
Derick
September.
Yes please.
cheers
Derick
solution for that could be to
>remove that user name in brackets that just repeats the linked name - e.g
>bukka (bukka). That would be nice to do as part of the "implementation" for
>this... :)
>
>Regards
>
>Jakub
It's the long commit hash in the table that makes it wide in this case.
But I can have a look at getting rid of the duplication (regardless of whether
the RFC passes)
cheers
Derick
;> https://news-web.php.net/php.internals/128477
>
>Looks like your request was already granted by somebody. Small
>reminder to whoever did so to announce it publicly, as otherwise I get
>pings on why it hasn't already happened. :)
>
>Cheers
I'm pretty sure I CCed this list when I did approve it.
cheers
Derick
less of an issue.
cheers
Derick
ce anything odd, wrong, or not working
after the move.
I'm intending to make the switch tomorrow morning, at around 11:30 BST.
Let me know if you have any questions.
cheers,
Derick
Hi,
On Thu, 31 Jul 2025, Derick Rethans wrote:
> On Thu, 31 Jul 2025, Mathieu Rochette wrote:
>
> > And when working on that I noticed that PHP lists were wrongly sent
> > the mails with `Precedence: bulk`. Is this something that could be
> > fixed?
>
> I can ce
xactly `List-Id: internals.lists.php.net`.``
We can easily change the List-Id header too, as long as I don't need to
add a manual description to all 124 of them. So for now, I would suggest
to change them to "List-Id: ". Would that work?
cheers,
Derick
--
https://derickrethans.n
On 29 July 2025 17:23:40 BST, Calvin Buckley wrote:
> I have not changed the vote names since I don't
>know if that will break the existing polls.
I can confirm that that would have broken it.
cheers
Derick
se don't add abstention to STV votes. If you select fewer options than you
can, that is already an abstention.
STV is really only used for secondaries (and release managers) anyway, so I
would rather see this not get more complicated.
cheers
Derick
case 'v': coptions |= PCRE2_ALT_EXTENDED_CLASS;
>ZEND_FALLTHROUGH;
>+#endif
> case 'u': coptions |= PCRE2_UTF;
> /* In PCRE, by default, \d, \D, \s, \S, \w, and \W recognize only
> ASCII
> characters, even in UTF-8 mode. However, this can be changed by
> setting
>
>```
>
>What do we think?
>
>[1] https://github.com/tc39/proposal-regexp-v-flag
Yes, please.
cheers
Derick
us to know whether you or somebody else has checked what
the effect of this change on existing code bases would be?
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
ze, so let's try to fit into the lines and deliver the value to
> PHP 8.5.
I'm not so keen on trying to rush things before meeting a deadline, but
I think that this addition seems entirely reasonable.
cheers,
Derick
replacement for:
mb_regex_encoding($fromEncoding);
mb_ereg_match($pattern, $string);
be:
pcre_match($patern, iconv($fromEncoding, 'UTF-8', $string));
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Co
does not seems to include an analysis
of the impact.
I can almost guarantee you that this is going to 'break'
(by a deprecation warning?) a lot of code. Even the changes made for
symfony seem non-trivial, and easy to get wrong
(https://github.com/symfony/symfony/pull/60890/files).
But we don't know, as there is no data on this — that's why I feel that
this is not a mature enough RFC.
cheers,
Derick
e thorny.
I only really have one comment — why wait until (specifically) PHP 9,
and not PHP-next (the one after 8.5)?
cheers,
Derick
s://github.com/php/php-src/pull/18896
I think this is an excellent idea.
I left a review on the PR, with a suggestion to improve the exception
message (slightly):
https://github.com/php/php-src/pull/18896/files#r2204824115
cheers,
Derick
On Fri, 4 Jul 2025, Tim Düsterhus wrote:
> On 7/3/25 18:04, Derick Rethans wrote:
>
> > The intention behind the filter extension was that admins can set a
> > default filter for *all* data coming in through this
> > `filter.default` setting as a "safe" fallbac
ave a good enough reason to be deprecated and
> might be still used. I don't see any problem with keeping them.
+1
cheers,
Derick
See the top comment on
> https://www.php.net/manual/en/function.filter-input.php#115086
>
> Maybe we should just unbundle that whole extension?
Certainly not. It has been the recommended way of accepting incoming
request variables since whenever we removed magic quotes.
cheers,
Derick
--
https:/
7; (I know, it's rather ugly
and the list of options is vast:
https://www.unicode.org/reports/tr35/tr35-collation.html#Common_Settings
cheers,
Derick
On 10 July 2025 06:28:39 CEST, Daniel Scherzer
wrote:
>* https://wiki.php.net/rfc/datetime_and_daylight_saving_time was accepted
>in 2011
>
>Is anyone still working on these?
Sort of, as part of new date time work.
cheers
Derick
inadvisably
deprecated).
I would therefore *undeprecate* filter.default, and allow these filter
functions are they currently are, because they implement the original
design idea behind this extension.
cheers,
Derick
On Mon, 30 Jun 2025, youkidearitai wrote:
> 2025年6月30日(月) 18:49 Derick Rethans :
> >
> > On Mon, 30 Jun 2025, youkidearitai wrote:
> >
> > > I have just started add locale for grapheme_* functions.
> > > https://wiki.php.net/rfc/grapheme_add_locale_for_cas
m/php/php-src/pull/18705
>
> As with every RFC, a 2/3 majority is required.
> Voting ends 2025-07-16 00:00:00 UTC.
I have voted "no" on this, as it's 2025, and we really shouldn't be
introducing ASCII-only functions.
cheers,
Derick
e to use strings for locales?
- How are locale strenghts handled, such as the
primary/secondary/tertiary modes of ICU — these influence the
matchy-ness of characters.
For all these situations, there should also be tests, but that's an
implementation detail.
cheers,
Derick
--
#x27;s stripos() that's
>wrong, because it's misleading as it only works on ASCII.)
>
>The ideal answer would be Derick's built-in String object RFC, which I don't
>think has been touched in a while, sadly...
>
>--Larry Garfield
That lives here, and ought to work fine as an extension for PHP 8.3+:
<https://github.com/derickr/php-text>
It works on graphemes, groups of Unicode code points that make up a letter. It
also handles strings in multiple locales.
It doesn't yet have a contains method.
cheers
Derick
ues with it (Immutable vs non-Immutable, or not
having dedicated types for timezoned/local dates, and instants, for
example).
cheers,
Derick
a252628668661313e022941779a
I have not heard complaints.
cheers,
Derick
t;
>Thank you in advance.
>
>Ignace Nyamagana Butera
I've added you to the RFC group.
cheers
Derick
ave permissions to see the RFC edit history,
>so not sure how long ago this was changed.)
I think you can now, as you've created an account?
We have to require that as the version histories were absolutely hammered by
bots, and it's not a cheap operation.
cheers
Derick
Hi,
It seems the poll is now closed, but the RFC is still listed in the
"In voting phase" section, and the Status is still "Voting". Would you
please have a look at that?
cheers,
Derick
On Mon, 26 May 2025, Daniel Scherzer wrote:
> Hi internals,
>
> Vo
On 8 June 2025 14:07:31 BST, Nick wrote:
>Hey all,
>
>Can someone please grant me RFC edit access?
>I’d like to fix two typos in our "Readonly hooks” RFC.
>
>User: nicksdot
I have done so.
cheers
Derick
apheme_setlocale($locale);
>grapheme_icontains($haystack, $needle);
>```
>
>First, grapheme_* function supports locale.
>Second, add grapheme_icontains function for case insensitive version
>for str_contains. .
I don't think it's a good idea to rely on a global state containing the locale.
cheers
Derick
;t do it locale dependent:
<https://www.php.net/manual/en/function.grapheme-stripos.php>
PHP could really do with a locale aware, grapheme aware, set of Text utilities.
I have a prototype at <https://github.com/derickr/php-text> where this
suggested function also would fit in.
cheers
Derick
osix (such as posix_getrlimit) and DNS related functions.
This also allows for polyfills.
cheers
Derick
e
>that into the RFC draft.
>
>Thanks!
>Daniel
I've added you to the RFC group.
cheers
Derick
uld probably not even allow the stable ``$code`` in here, as I have
seen from experience people don't really check for them.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
"-1.a"); // true
>> var_dump(-1.5 ~= "-1.aaa"); // false
>> var_dump(NULL ~= "blablabla"); // false
>> ```
>>
>> Note that this does not support all possible Opcache optimizations
>> _yet_, nor does it support the JIT yet.
>> However, there are no real blockers to add support for that.
>>
>> I look forward to hearing you!
>>
>> Have a nice first day of the month ;)
>> Kind regards
>> Niels
>
>Naturally, the degree of closeness for strings or for floats should be
>controlled by an ini setting. Maximum flexibility!
>
>--Larry Garfield
You got to be joking! Everybody knows ini settings make things unportable. I
suggest we introduce AI to determine the closeness instead.
cheers
Derick
Hi,
The actual downtime was about 45 seconds, and the wiki is now running on
the new host.
Most of the requests seem to be from AI bots and crawlers though :-/.
Please let me (and systems@) know if you encounter any problems.
cheers,
Derick
On Wed, 2 Apr 2025, Derick Rethans wrote:
>
tomorrow
at 15:00 UTC, to make sure none of us update wiki pages when the data is
being transferred and the CDN has realised the new origin host.
If this is not convenient, please reach out and we can look at another
time.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https
ere.
I would urge you to familiarise yourself with the Mailinglist Rules
again:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
cheers,
Derick
x27;s the last instruction of a function?
>
>Thank you
No.
It has no effect. At the end of the function PHP would remove a ref to the
variable anyway. Setting it to null first is an action that will take time,
unless opcache is turned on and realises it's a useless action.
cheers
Derick
Hi,
To see to be posting a reply to nearly every other email on this thread. I'd
recommend you have another read through our mailing list rules:
<https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md>
cheers
Derick
On 8 March 2025 22:28:58 GMT, Daniil Gentili wr
ture' in PHP
9.0 (now it's only a deprecation warning silencer).
That's the same with this suggested NoDiscard, it doesn't change how a
program is run — it merely adds a warning.
cheers,
Derick
it inconvenient to have more than one
> > sentence in an error message, which is why we're struggling with coming
> > up with something better.
>
> Just spitballing:
>
> "Return value of foo() is not used, on foo.php line 5: here>"
>
> Fiddle with the wording as needed, but by having a colon and then the
> user text, it makes it clear it's a separate statement, and can be as
> flexible as a statement in your chosen language wants to be.
PHP always adds "in file.php on line 42" to the end, so that wouldn't
work.
cheers,
Derick
es sense to you.
>
> We've chosen #[NoDiscard] as it's also used in C and C++. See [1] for
> the full list of references. If you feel this doesn't fit with PHP, we
> welcome other suggestions.
I think it fits, and there is already precedence.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
ghts about the filter_input()
> deprecation?
I don't think they need to be deprecated, just because it is
"confusing". They were added specifically so that you could operate on
the original raw data.
cheers,
Derick
t; - RFC: https://wiki.php.net/rfc/marking_return_value_as_important
> - Implementation: https://github.com/php/php-src/pull/17599
Looks reasonable to me.
What's the reason why this emits a warning though, instead of throwing
an Exception? I'm sure you thought of it, but it would be nice to have
that consideration mentioned in the RFC.
cheers,
Derick
On Tue, 14 Jan 2025, Derick Rethans wrote:
> I have just opened the vote on the "Consolidate Coding Standards
> Policy Document". The vote will run until January 28st, 16:00 UTC.
>
>
> https://wiki.php.net/rfc/consolidate-coding-standard-policy-document#propos
Hi,
I have just opened the vote on the "Consolidate Coding Standards Policy
Document". The vote will run until January 28st, 16:00 UTC.
https://wiki.php.net/rfc/consolidate-coding-standard-policy-document#proposed_voting_choices
cheers,
Derick
--
https://derickrethans.
On Tue, 24 Dec 2024, Ben Ramsey wrote:
> > On Dec 23, 2024, at 19:06, Derick Rethans wrote:
> >
> > On Sun, 22 Dec 2024, Ben Ramsey wrote:
> >
> >>> On Wed, Dec 18, 2024 at 11:39 Derick Rethans wrote:
> >>>
> >>> I wo
On Sun, 22 Dec 2024, Ben Ramsey wrote:
> On Wed, Dec 18, 2024 at 11:39 Derick Rethans wrote:
>
> > I would like to propose the "Consolidate Coding Standards Policy
> > Document" RFC, which follows up from the Policy Repository RFC[1]'s
> > future scope
ANDARDS.md file from the
php-src repository:
https://wiki.php.net/rfc/consolidate-coding-standard-policy-document
cheers,
Derick
[1] https://wiki.php.net/rfc/policy-repository
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider suppo
On 20 November 2024 20:24:32 CET, Theodore Brown wrote:
>On Wed, Nov. 20, 2024 at 13:03 Derick Rethans wrote:
>
>> On 20 November 2024 19:26:12 CET, Theodore Brown wrote:
>>> On Wed, Nov 20, 2024 at 09:23 Kamil Tekiela wrote:
>>>
>>>> Do you know why the
ased templates for the xdebug.org site use this style. I don't
think it's atrocious, and quite a bit nicer than the "new" syntax.
It's also not a decades old choice (and not even by me).
cheers
Derick
makes
everything so much more of a pain for us.
I strongly recommend you change your opinion on this.
cheers
Derick
uch a limit. I especially think that the suggested limit of 5, or
even 3, is not a good idea.
The example that the issue links to to fix a vulnaribility in is:
include $_GET['page'];
Which is... yeah.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | ht
er is pretty much the
same as the JS tracker. And as it does HTTPS requests from the PHP
application to Matomo, instead of a JS tracker, this seems like a
better solution, which is also more customisable.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
> can fix. I hope that the raw analytics data is just as locked down as
> the server logs...
The raw server logs will definitely not be opened up, and neither will
any other raw data.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
hub.com/xdebug/xdebug/blob/master/LICENSE), which is the PHP
License 3.01, but with s/PHP/Xdebug.
I've been wanting to change that for ages, but it requires approval from
all contributors, and that's not going to happen easily.
cheers,
Derick
--
https://derickrethans.nl | https
ed_enums
>
> We look forward to your feedback and hope for a constructive discussion.
My only comment is that I don't think you should have three different
votes, but just the single one for the whole proposal.
cheers,
Derick
ared_objects() that behaves like get_declared_classes() currently
>does.
Objects are instantiated classes, and not declared elements, so that name
wouldn't make sense.
cheers
Derick
On Mon, 9 Sep 2024, Christoph M. Becker wrote:
> On 09.09.2024 at 17:52, Derick Rethans wrote:
>
> > - Documentation on how to write tests
> > (https://qa.php.net/write-test.php), and how to handle bug reports
> > (https://qa.php.net/handling-bugs.php); which should
way?
Yes. Making it clear what happens is useful.
> 2. Should the capability to overload comparison operators be provided
> in the same RFC, or would it be better to separate that into its own
> RFC? Why do you feel that way?
I'm not too worried, but usually smaller RFCs have a larger chance of
being accepted.
cheers,
Derick
gt;
> As such, I am proposing an RFC to turn this class into an opaque
> object.
>
> RFC: https://wiki.php.net/rfc/directory-opaque-object
I see you want to make "new Directory" not work - but wouldn't it make
more sense if that was the *prefered* way instead of using dir() ?
cheers,
Derick
gt;After trying to get it to work unsuccessfully I am ready to try something
>else.
>
>So which IDE would you recommend for php-src development?
I use vim. With the ctags plugin, but that's mostly it. Debugging with gdb and
valgrind.
I avoid docker, as that had always made it harder to do things.
cheers
Derick
On Wed, 11 Sep 2024, Christoph M. Becker wrote:
> On 11.09.2024 at 15:51, Derick Rethans wrote:
> >
> > Ideally, instead of having downloads.php.net/~windows, we have
> > downloads.php.net/windows which is a Git repository for the series
> > files, but it is probably
mmented out through an
#ifdef.
cheers
Derick
On Wed, 4 Sep 2024, Derick Rethans wrote:
> On 4 September 2024 21:32:10 BST, Rob Landers wrote:
> >On Wed, Sep 4, 2024, at 22:26, Derick Rethans wrote:
> >> On 4 September 2024 21:15:55 BST, Rob Landers wrote:
> >> >
> >> >I receive the following er
nd BC policy.
But XML parsing is such an integral part of PHP, that this absolutely
should be in core. For *many* users, if it's not in core, they can't use
it. Or at least that used to be a big problem.
> Having added support for PIE for ext/csv, which was very easy, [2] I
> hope when this tool is finally ready, and we ditch PECL, we will start
> unbundling extensions so that they are not constrained by the PHP
> Engine release cycle.
I believe that that is a decision for internals, not just "we".
cheers,
Derick
maintain, and
> distribute extensions with.
It's going pretty well: https://github.com/php/pie/commits/main/ — I
think there will soon be a "have a look at this" email. There is a
tentative plan to have a first release to coincide with PHP 8.4
cheers,
Derick
--
https://
On Sun, 8 Sep 2024, Christoph M. Becker wrote:
> On 08.09.2024 at 16:58, Derick Rethans wrote:
>
> > I think it needs some good thinking through first. I also don't
> > believe the RFC system is something we need to use for deciding how
> > to serve files.
>
&g
tual
reports work any way. This also takes up nearly 70GB! of data. I
recommend we just delete it all.
Opinions?
cheers,
Derick
the RFC system is something we need to use for deciding how to serve
files.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
On 4 September 2024 21:32:10 BST, Rob Landers wrote:
>On Wed, Sep 4, 2024, at 22:26, Derick Rethans wrote:
>> On 4 September 2024 21:15:55 BST, Rob Landers wrote:
>> >Hello Internals,
>> >
>> >I receive the following error when saving an RFC:
>
ve something?
And it really helps to have really accurate timings of when it happens as the
log is so noisey.
cheers
Derick
by this.
>
>Christoph
Shouldn't we have bumped the API number for this? Better safe than sorry.
And I'm wondering why we have no tests for ABI breaks here? I'm sure that I
have seen a report (from Remi?) that highlighted these breakages when I was
still involved in the mongodb extension.
cheers
Derick
w to end up on the graph. Otherwise it
>gets too noisy with very many people only sending in one or two emails per
>day. If you change the window to 7 days, you should show up since you've been
>pretty active in the last week.
This is off topic. Please don't spoil this thread with this. Remeber that over
a thousand people receive this.
cheers
Derick
x as it was only used for placeholders. It's likely something that
can be handled in the parser.
Having an opcode for it, that does internal reflection, is what I'm
unsure about.
cheers,
Derick
very few
third party PECL developers wanted to spend the time doing that,
consdiering Docbook isn't the easiest to use.
cheers,
Derick
MPSS as raised in
https://github.com/php/doc-en/pull/1674) is probably something I *won't*
favour.
Explaining how to install PHP with homebrew, apt or yum makes perfect
sense to me. Nobody really ought to go to www.php.net/download and
compile PHP themselves. But that's the only installation instructions
that we have.
cheers,
Derick
d that the "new" languages will "win". If we
don't promote how modern PHP Development works, then there will be more
"PHP, a fractal of bad design" articles to come for decades.
We *must* do better than this. It probably doesn't all need to be in the
documentation (doc-en), but it absolutely belongs on our website.
cheers,
Derick
On Wed, 10 Jul 2024, Derick Rethans wrote:
> We discussed this during one of our foundation meetings, and we propose:
>
> - to delete all notes with a rating less than -5 that are older than a
> year.
As general consensus was that this correct, I will be creating a script
for t
s,
>Marc
>
I'll get this sorted. IMO this is also a bug fix, but as we are in feature
freeze I'll ask thr release managers.
cheers
Derick
Hi!
Arnaud, Larry, and I have been working on an article describing the
state of generics and collections, and related "experiments".
You can find this article on the PHP Foundation's Blog:
https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/
cheers,
Derick
t language,
bordering on trolling.
You have therefore been given a 3-month timeout, which will be enforced
by blocking you from sending email to the php.net domain, including
subdomains.
Evading, or attempts to evade, this restriction will result in longer
expulsions.
with kind regards,
Derick R
On 15 August 2024 18:42:58 BST, Lanre wrote:
>On Thu, Aug 15, 2024 at 11:33 AM Derick Rethans wrote:
>
>> On 15 August 2024 18:10:11 BST, Lanre wrote:
>>
>> >You're embarrassing yourself John, read my very first paragraph (you got
>> this).
>>
>&g
d email client (think alpine or
mutt).
Otherwise, it's probably best to subscribe to the normal list if you want to
reply.
Let me know if you need further help.
cheers
Derick
On 15 August 2024 18:10:11 BST, Lanre wrote:
>You're embarrassing yourself John, read my very first paragraph (you got
>this).
We have said this before, but you *really* need to stop using condescending
language, and ad-hominems like this.
cheers
Derick
or even objections?
Archive it, I'd say. Do I need to press buttons for that?
cheers,
Derick
resenting my concern.
I understand that new versions require changes.
One of my issues is, is that so far I could not find a way to replicate
existing functionality with this patch applied.
The RFC does not mention a BC break, nor does it have an entry for
UPGRADING.INTERNALS either.
cheers
Derick
On Mon, 5 Aug 2024, Christoph M. Becker wrote:
> On 05.08.2024 at 17:42, Pierre Joye wrote:
>
> > On Mon, Aug 5, 2024, 10:03 PM Derick Rethans wrote:
> >
> >> Instead of having to deal with tickets, wouldn't be be easier if
> >> the compiler they used
On Mon, 5 Aug 2024, Christoph M. Becker wrote:
> On 05.08.2024 at 12:49, Derick Rethans wrote:
>
> > On Thu, 1 Aug 2024, Ilija Tovilo wrote:
> >
> >> Hence, it seems like it would be ok to bump our C compiler
> >> requirement to C11. We'd like to make
function names found in a namespace
> context are global, without a namespace lookup?”
I don't beleive that we should introduce a switch for this at all, just
like the conclusion was in https://wiki.php.net/rfc/use_global_elements
cheers,
Derick
1 - 100 of 1947 matches
Mail list logo
