On Mon, May 12, 2025, at 8:57 PM, Larry Garfield wrote:
> I hereby open the vote on the Pipe operator RFC:
>
> https://wiki.php.net/rfc/pipe-operator-v3
>
> The vote will run until 26 May.
The vote is now closed. The final tally is 33 Yes to 7 No, or about 82%. The
RFC passes.
Thank you everyo
On Wed, May 14, 2025, at 10:36 PM, Theodore Brown wrote:
> On Wed, May 14, 2025 at 09:08 Larry Garfield wrote:
>
>> On Tue, May 13, 2025, at 5:55 PM, Ilija Tovilo wrote:
>>> On Tue, May 13, 2025 at 3:58 AM Larry Garfield
>>> wrote:
I hereby open the vote on the Pipe operator RFC:
>
On Wed, May 14, 2025 at 09:08 Larry Garfield wrote:
> On Tue, May 13, 2025, at 5:55 PM, Ilija Tovilo wrote:
>> On Tue, May 13, 2025 at 3:58 AM Larry Garfield
>> wrote:
>>>
>>> I hereby open the vote on the Pipe operator RFC:
>>>
>>> https://wiki.php.net/rfc/pipe-operator-v3
>>
>> It looks like t
On Tue, May 13, 2025, at 5:55 PM, Ilija Tovilo wrote:
> Hi Larry
>
> On Tue, May 13, 2025 at 3:58 AM Larry Garfield wrote:
>>
>> I hereby open the vote on the Pipe operator RFC:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>
> It looks like the example under "Rejected Features" is wrong.
>
> //
Hi Larry
On Tue, May 13, 2025 at 3:58 AM Larry Garfield wrote:
>
> I hereby open the vote on the Pipe operator RFC:
>
> https://wiki.php.net/rfc/pipe-operator-v3
It looks like the example under "Rejected Features" is wrong.
// With Elixir style
$foo
|> bar(...)
should be
$foo
|> bar()
Al
On Tue, May 13, 2025, at 1:41 PM, Levi Morrison wrote:
> On Mon, May 12, 2025 at 8:00 PM Larry Garfield wrote:
>>
>> I hereby open the vote on the Pipe operator RFC:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>>
>> The vote will run until 26 May.
>
> Hey, Larry, quick check:
>
>> Supporting p
On Mon, May 12, 2025 at 8:00 PM Larry Garfield wrote:
>
> I hereby open the vote on the Pipe operator RFC:
>
> https://wiki.php.net/rfc/pipe-operator-v3
>
> The vote will run until 26 May.
Hey, Larry, quick check:
> Supporting pass-by-ref parameters in simple cases is quite easy, and
> a naive i
Thank you for your work on this.
While I will enjoy this feature if it passes, it irks and saddens me that...
once\again::PHP->has|>added
a.feature.other.languages.only.need.dot.for
That isn't your fault, and any hope of changing that about the language
left the station decades ago.
On Mon, May
2021-07-20 11:12 GMT+02:00, Marco Pivetta :
> Hey Larry,
>
> On Sat, Jul 17, 2021 at 6:00 PM Larry Garfield
> wrote:
>
>> Hi Marco. Thank you for your explanation, even if I naturally disagree.
>>
>> Out of curiosity, what sort of additional
>> power/capability/flexibility/etc. would, in your min
Hey Larry,
On Sat, Jul 17, 2021 at 6:00 PM Larry Garfield
wrote:
> Hi Marco. Thank you for your explanation, even if I naturally disagree.
>
> Out of curiosity, what sort of additional
> power/capability/flexibility/etc. would, in your mind, justify pipe or
> similar being a native feature? PH
> Pol Dellaiera (https://github.com/drupol) has done a lot of work around
> this stuff, specifically the type inference bit, in
> https://github.com/loophp/combinator , so I see hope to get better types at
> a later stage.
I don't see a pipe combinator in there, but maybe I can't see it
through
On Sat, Jul 17, 2021, at 9:48 AM, Marco Pivetta wrote:
> Hey Larry,
>
> I just voted "NO" on this: it took me a long time to decide, because I've
> been vouching for pipe-alike operators myself for a while.
>
> The reason why I voted "no" is that this is feasible with a `pipe(callable
> $first, c
Hey Larry,
I just voted "NO" on this: it took me a long time to decide, because I've
been vouching for pipe-alike operators myself for a while.
The reason why I voted "no" is that this is feasible with a `pipe(callable
$first, callable ...$piped)` function, without having to add syntax/AST for
it
On Tue, Jul 6, 2021, at 6:54 PM, Bob Weinand wrote:
> Hey Larry,
>
> there's still ongoing discussion on the semantics, and mirroring
> implementation defined semantics from the implementation into the RFC
> is not the way to go. The RFC should discuss reasons of why semantics
> were chosen and
Hey Larry,
there's still ongoing discussion on the semantics, and mirroring implementation
defined semantics from the implementation into the RFC is not the way to go.
The RFC should discuss reasons of why semantics were chosen and the
implementation then be decided upon it. Describing it as "d
15 matches
Mail list logo
