Hi!
> https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21.
>
> That ticket proposes the following:
>
>> I propose that we disable the ability to have concrete types included in the
>> serialized metadata by
>> providing an empty classlist to the unserialize call in the PHAR
Hi internals,
https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21.
That ticket proposes the following:
> I propose that we disable the ability to have concrete types included in the
> serialized metadata by
> providing an empty classlist to the unserialize call in the PHAR
Hi all!
I would like to start discussion about the «FFI Improvements» RFC. At the
moment, I do not have the right to create wiki page, so I post it on the
github:
https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md
The proposal:
- Contains
Hey internals,
I have updated the RFC with 2 changes:
1. Made the RFC target PHP 9.0 for enforcing `void` rules implicitly.
2. Added a secondary vote for allowing explicit `void` return type declaration.
I will be opening the vote again on Wednesday (July 8th).
Best regards,
Benas
On Fri, 3
On Mon, Jul 6, 2020 at 6:33 PM Benjamin Eberlei wrote:
>
>
> On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels <
> arnold.adaniels...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'd like to start the discussion of the "Strict operators directive" RFC
>> version 1.5. This RFC proposes a new directive
On Mon, Jul 6, 2020 at 6:22 PM Marco Pivetta wrote:
> Hey Arnold,
>
> Perhaps it makes sense for <=> to still operate with other types, as long
> as they are uniform? Specifically:
>
> * error: 1 <=> "1"
> * ok: "a" <=> "b"
> * ok: true <=> false
>
Using `==`, `!=`, and `<=>` with string
Hey Josh,
Similar proposals were raised recently for `__toArray()`: see
https://externals.io/message/108369#108369
I'd endorse avoiding object-to- casts via cast operations: they are
a good source of bugs.
My rationale for the discouragement of magic cast methods is explained with
some code
On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels
wrote:
> Hi all,
>
> I'd like to start the discussion of the "Strict operators directive" RFC
> version 1.5. This RFC proposes a new directive strict_operators, which
> limits the type juggling done by operators to avoid unexpected results.
>
>
Hey Arnold,
Perhaps it makes sense for <=> to still operate with other types, as long
as they are uniform? Specifically:
* error: 1 <=> "1"
* ok: "a" <=> "b"
* ok: true <=> false
Similar for sorting: I use <=> to differentiate multi-dimensional arrays:
perhaps it should error if the array
Hi all,
I'd like to start the discussion of the "Strict operators directive" RFC
version 1.5. This RFC proposes a new directive strict_operators, which limits
the type juggling done by operators to avoid unexpected results.
https://wiki.php.net/rfc/strict_operators
There are some significant
On Fri, Jul 3, 2020 at 4:35 PM Nikita Popov wrote:
> On Mon, Jun 29, 2020 at 5:13 PM Nikita Popov wrote:
>
>> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov
>> wrote:
>>
>>> On Tue, May 5, 2020 at 3:51 PM Nikita Popov
>>> wrote:
>>>
Hi internals,
I've recently started a thread
Apologies, first time, still learning and have no historical context - timing
is what it is.
Proposal type: Concept
Implementer: Unknown, fallback to me after slow learning
Presumed simple implementation as the pattern should already be in place:
Cast of (string) -> __toString() - already
12 matches
Mail list logo
