On Sat, Jul 23, 2016 at 8:15 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Glad it makes sense. :) I realise "return $$" would have to have some > special handling, but it would feel more natural to me. I guess the only > concern is what happens when a pipeline has a return terminal and is used in > expression context: > > $foo = bar() |> baz($$) |> return $$; > // theoretically translates to this invalid PHP: > $foo = return baz(bar()); > > I'm not sure how easily the compiler would be able to pick up that that's an > illegal construction. > Right, which is where I'm hesitant to go down that road.
> I was going to say that "yield" would be worth considering at the same time, > but presumably that's already legal, because yield can appear as an > expression (to receive variables sent into a co-routine). > Yep. Perfectly valid as-is, so a non-issue. > It's a shame neither "echo" nor "print" is useful for getting $$ out to > screen and leaving it unchanged (echo doesn't work in expression context at > all; print doesn't have a useful return value). > Yeah, those pegs really don't fit into this hole... > It might be worth coming up with some examples to add to the RFC where $$ is > used in an expression other than a function call, because I wasn't entirely > sure when I read it if that was even allowed. It might also clear up some of > the confusion around this being anything to do with OO. > > Off the top of my head, how about some maths: > > $foo * $bar > |> 2 ** $$ > |> sin($$ + 1) > |> $$ / 20 > |> $result = $$; > > Compiles to: > > $result = sin((2 ** ($foo * $bar)) + 1) / 20; > > Or: > > $temp = $foo * $bar; > $temp = 2 ** $temp; > $temp = sin($temp + 1); > $result = $temp / 20; > Fair point, I took those as a given, but they should be added. (And yes, they're valid). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
