Hey, > Am 20.07.2026 um 14:34 schrieb Tim Düsterhus <[email protected]>: > > Hi > > On 2026-07-19 10:35, Nick Sdot wrote: >> I think the latter would be more intuitive: assign the result of piping to >> the variable. I know that `|>=` follows the established `foo=` convention >> for compound assignments like `??=` or `.=`; which is an argument in its >> favour. Still, I think `=|>` better communicates how this particular >> operation expands. Especially when considering future additions like the >> ones Vadim proposes in future scope. > > I believe language consistency is of utmost importance for users to learn and > remember fewer special cases. > >> One additional soft argument is that text ligatures will show >= as ≥ which >> will just add to the confusion if modifying operators as Vadim proposes in >> future scope would ever be added. > > It's also not uncommon for them to show |> as ▷, because |> is established as > a pipe operator. > >> Long story short: `=|>`over `|>=` IMO has a lot of appeal. > > I disagree. It looks more like a special form of `=>` rather than an > assignment, which loops back to the “consistency” argument above. > > Best regards > Tim Düsterhus
I wholeheartedly agree with Tims assessment here. Also, it's "pipe then assign" - "|>, followed by =". I absolutely don't like the pipe operator, but pipe-assign (plus some pipes afterward possibly) makes a lot of sense. "Transform this variable", without any repetition. I'm in favour of this proposal as a whole too. I just have one more question to the RFC author, which I see in the implementation, but the RFC is not explicitly noting: Is it intentional that fetching is repeated? It will literally desugar $a->b->c |>= strtolower(...); to $a->b->c |>= strtolower($a->b->c); resulting in double execution of e.g. property get hooks. Which in my opinion ought not be the proper behaviour. I acknowledge, that the behaviour is slightly different from the generic operator-assign that other unrelated code can be accessed in between, making RW fetch indirects unsafe - this could obviously be solved perfectly with ad-hoc references in cases the container is an indirect after RW fetching. (i.e. $a[0][0] |>= intval(...); could be like $_container = &$a[0]; $_container[0] |>= intval($_container[0]); - for objects containers or non-nested stuff, it's obviously unneeded.) Which would the be quite close to actual semantics of other assign-ops. Nice job on the RFC, Bob
