Re: [PHP-DEV] [RFC] Transform void into an alias for null

2025-06-03 Thread Anton Smirnov
On 03/06/2025 18:20, Gina P. Banyard wrote: On Tuesday, 3 June 2025 at 02:36, Anton Smirnov wrote: On 02/06/2025 23:50, Rowan Tommins [IMSoP] wrote: I agree the type hierarchy you describe is weird, but rather than throwing away the functionality completely, I wonder if we can make it more

Re: [PHP-DEV][RFC] Deprecate type juggling to and from bool type within the function type juggling context

2025-06-03 Thread Anton Smirnov
On 02/06/2025 19:11, Gina P. Banyard wrote: Hello internals, This is the first RFC out of a set of type system related RFCs I want to propose for PHP 8.5. It also used the recently enabled Markdown support on the wiki, so there might be a few oddities. The RFC proposes to deprecate implicit t

Re: [PHP-DEV] [RFC] Transform void into an alias for null

2025-06-02 Thread Anton Smirnov
On 02/06/2025 20:01, Larry Garfield wrote: The result of this RFC is that the following would no longer be an error, yes? function test(): void { print "test"; } // This currently gives an error, but you propose that it // would change to set $val to null? $val = test(); There is no error:

Re: [PHP-DEV] [RFC] Transform void into an alias for null

2025-06-02 Thread Anton Smirnov
On 02/06/2025 23:50, Rowan Tommins [IMSoP] wrote: I agree the type hierarchy you describe is weird, but rather than throwing away the functionality completely, I wonder if we can make it more consistent: - Make "no return type declared" and "mixed" equivalent - Make "void" a sub-type of "null"

Re: [PHP-DEV] RFC: Single-Expression functions

2025-05-22 Thread Anton Smirnov
Hi Dmitriy On 22/05/2025 12:24, Dmitry Derepko wrote: > I'm aware that Larry Garfield previously proposed a similar feature > several years ago, though it unfortunately didn't pass the voting stage. > I would like to respectfully suggest that using "=" instead of "=>" to > separate declaration an

Re: [PHP-DEV] Forced named parameters

2025-05-22 Thread Anton Smirnov
Hi Alwin On 19/05/2025 19:37, Yogarine wrote: Moreover, what if I don't need a variadic parameter, but would like to declare that the function's interface requires named arguments (because I don't want to be tied to locking parameters to specific positions). If you don't need a variadic, you

[PHP-DEV] Forced named parameters

2025-05-19 Thread Anton Smirnov
Hi everyone, Looking [RFC] Clone with v2, especially Larry's message (https://externals.io/message/127353#127399) I'm thinking that it might be a good idea to allow forcing function calls to use named arguments. Python has it by defining arguments after the variadic argument: https://peps.pyth

Re: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24

2025-04-30 Thread Anton Smirnov
On 30/04/2025 08:05, youkidearitai wrote: Hi, Internals Oniguruma(鬼車) maintenance was ended on April 24, 2025. https://github.com/kkos/oniguruma This library uses mbregex in php-src. There is forked library in Onigumo(鬼雲). https://github.com/k-takata/Onigmo How do we do that? - Move to Onigumo

Re: [PHP-DEV] Return When

2024-11-26 Thread Anton Smirnov
On 26/11/2024 18:10, Volodymyr Volynets wrote: > I have an idea which will save a lot of code. I am proposing to add": > > return when [condition], [return value]; > > This construct will remove a lot of ifs statements after method calls. > For example: > > $result = Class->method(); > if (!$resul

Re: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as Object Properties and Named Parameters in PHP

2024-09-03 Thread Anton Smirnov
On 03/09/2024 14:48, Anton Smirnov wrote: [new AAA, '123AnyChars%%!@#'](); Wrong example, sorry, should be (new AAA)->{'123AnyChars%%!@#'}();

Re: [PHP-DEV] Pre-RFC Discussion: Support for String Literals as Object Properties and Named Parameters in PHP

2024-09-03 Thread Anton Smirnov
On 02/09/2024 19:42, Christoph M. Becker wrote: On 02.09.2024 at 16:51, Mike Schinkel wrote: Generally I am one who welcomes new feature ideas, but I fear that string literals as object properties would break a valuable assumption that all properties must be a valid identifier. Without tha

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

2024-08-11 Thread Anton Smirnov
On 12/08/2024 00:36, Nick Lockheart wrote: So what I would propose is: (1) All string functions should state in the official man page if they are safe for UTF-8 or not. Reasonable but see below (2) Functions intended for working with text should be made UTF-8 safe. Define precisely UTF-8 s

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

2024-08-11 Thread Anton Smirnov
Hi Nick, As a developer who often deals with binary data (like bencode, ipv6 addresses and my own hacks for multibyte arithmetic) I would prefer that functions and syntaxes that allow me to work with bytes keep working with bytes, not characters or code points. So the closest solution would b

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

2024-08-11 Thread Anton Smirnov
To mbstring.func_overload On 8/11/24 19:22, Bilge wrote: Are we going back to PHP 6?

Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions

2024-03-04 Thread Anton Smirnov
On 03/03/2024 23:33, Kamil Tekiela wrote: > Hi Anton, > >> As I know some session-related middlewares force custom-only session_id >> handling by setting >> >> use_cookies = Off >> use_only_cookies = On >> >> and then using session_id(...) directly >> >> Example: >> https://github.com/m

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

2023-04-12 Thread Anton Smirnov
On Tue, 2023-04-11 at 11:57 +0100, G. P. B. wrote: > No, array_map will trigger the autoloader (actually strlen() will > trigger it once first) and the autoloader should then load the > array_map function from the My namespace. > However, if the autoloader does not correctly load the My\array_map()

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

2023-04-10 Thread Anton Smirnov
Hello George, I'm not sure I'm 100% correct but I think that this RFC still allows to call different functions for the same code, just not in the same run. Consider this pseudocode: //- funcs.php namespace My; function myfunc(...) { ... } function array_map(...) { ... } //- code1.php namespa

Re: [PHP-DEV] xoshiro** edge case (all zeros)

2022-08-04 Thread Anton Smirnov
ions choose to seed the RNG with 0x...0001 but that kinda inroduces bias > On Thu, 4 Aug 2022 at 20:33, Tim Düsterhus wrote: > > Hi > > > > On 8/4/22 10:09, Anton Smirnov wrote: > > > xoshiro** has a known edge case: all-zero seed > > > > Indeed

[PHP-DEV] xoshiro** edge case (all zeros)

2022-08-04 Thread Anton Smirnov
Hi! Randomness again. Sorry if I just missed some relevant discussion xoshiro** has a known edge case: all-zero seed generate()), PHP_EOL; // } It should be documented and/or handled It's only for a string seed, int seed is not affected -- Anton -- PHP Internals - PHP Runti

Re: [PHP-DEV] Negative values in PcgOneseq128XslRr64::jump($advance)

2022-07-31 Thread Anton Smirnov
On Sun, 2022-07-31 at 19:52 +0200, Tim Düsterhus wrote: > Hi > > On 7/31/22 17:50, Anton Smirnov wrote: > > I'm writing a polyfill for ext-random and I noticed a small > > weirdness. > > PcgOneseq128XslRr64::jump() accepts negative $advance where it > > a

[PHP-DEV] Negative values in PcgOneseq128XslRr64::jump($advance)

2022-07-31 Thread Anton Smirnov
Hi! I'm writing a polyfill for ext-random and I noticed a small weirdness. PcgOneseq128XslRr64::jump() accepts negative $advance where it automagically becomes unsigned positive. Does it make sense or maybe it's better to throw a ValueError there? -- Anton -- PHP Internals - PHP Runtime Develop

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

2022-07-01 Thread Anton Smirnov
On Fri, 2022-07-01 at 16:11 +0200, Hans Henrik Bergan wrote: > > As far as we are aware, only two languages in widespread use > > require variables to be explicitly closed over: PHP and C++. All > > other major languages capture implicitly, as is proposed here. But do any of them auto-capture by v

Re: [PHP-DEV] [RFC] Disjunctive Normal Form Types

2022-03-19 Thread Anton Smirnov
On Sat, 2022-03-19 at 16:38 +, G. P. B. wrote: > DNF types are a way to mix intersection and union types together in a > single type. > For example: >  - (A&B)|null >  - (Traversable&Countable)|array Hello George, I like your proposal. I would like to offer 2 suggestions however: 1. I think