Michał

Nice addition, but I would change syntax:

class User 
{
    public string $name {
        set($value) {
            if (strlen($value) === 0) {
                throw new ValueError("Name must be non-empty");
            }
            return $value;
        }
    }
 
    public function __construct(string $name) {
        $this->name = $name;
    }
}

I think the proposition is not "must have" option but it's ok

Interface should be contract which a class must fulfill. They should not include any implementation. If you want share implementation you can use traits.

I like the proposition, but I would use some special "variable" ($$) for piped value (see v1 proposition: https://wiki.php.net/rfc/pipe-operator) so you don't have to use closures inside pipe to place value

$name = 'my_user_name'
	|> str_replace('_', ' ', $$)
	|> strtolower($$)
	|> ucwords($$)
	|> trim($$);

I don't like mapping function names as strings too

For me, the most important argument is that the pipeline pattern is a tried and tested pattern, that this RFC builds upon. A couple of examples:

• league/pipeline
• laravel's pipeline

This RFC adds syntax to make using these kinds of pattern much more convenient.

On top of that, there's the argument that multiple modern languages support a pipe operator:

• Hack
• Haskall
• Ruby
• Elixir
• And more

Finally, I've had numerous occasions where a pipe operator would simplify my own code — I have more than a handful real life cases where this would be useful.