I wanted that yesterday, so definitely yes :)
Should target 3.4 when merging.

This is wrong, because if I do a dump($object, $foo, $bar), I know we will have $object but from an external point of view, this is not so obvious...

@Taluu in that case the last argument is the var that is returned ;)

dump($string, $float, $object)->method();

@Taluu in that case the last argument is the var that is returned ;)

Which means it is even less obvious than you think it was... maybe return func_get_args() or null in this case, so that it can't be misused?

That's the same thing (I read too fast), but still. If I am using echo, var_dump, error_log and so on, I am not expecting those to "return" the (last ?) argument. And returning all the args is not really intuitive too IMO.

This is making something fluent just for the sake of making it fluent : https://ocramius.github.io/blog/fluent-interfaces-are-evil/

This is just about easing inspecting some vars when developing. It's not just for the sake of making it fluent. Thanks to this, you just have to wrap a variable or an expression instead of writing a new line and possibly executing the same piece of code twice.

This is wrong, because if I do a dump($object, $foo, $bar), I know we will have $object but from an external point of view, this is not so obvious...

maybe return func_get_args() or null in this case, so that it can't be misused?

Returning func_get_args() would defeat the purpose of this, as you won't be able to chain.
What it returns in case of multiple arguments "does not have to be particularly obvious when reading", because you're not likely to read that code anyway: you generally are the one writing this code for debugging purpose so it won't remains. Either you know about the feature, how it behaves and use it, either you don't and keep dumping around the old way.

For the func_get_args() I agree, but on the other thing (returning something), I disagree.

Something that would be more convenient IMO would be to yield each value on multiple args, rather than arbitrarily returning the last arg

But what would be the usefulness of this in practice, appart from the debatable less arbitrary nature of the returned value? How would it be convenient? It'll return a generator and won't allow chaining, so again defeats the purpose of this PR.

When you dump multiple values, you're probably not using them inline anyways, so the benefit of simply adding and removing dump() around the variable would not be existent anyways...

Returning func_get_args() would defeat the purpose of this, as you won't be able to chain.

I wrote "in that case", meaning when you pass multiple vars.

Don't forget that the goal of this PR is it so make dump($object)->method(); works.

We can accept that this PR is a first step, and create new PRs later to improve the behavior of what's returned in the case of multiple arguments ?

@greg0ire you cannot make a function become a generator conditionally, as this is determined at compile time (based on the presence of a yield in it).

TIL 💡 , but I think you meant to answer to @Taluu

We can have it return the exact same list of things of course..

if ($moreVars) {
    return func_get_args();
}

return $var;

and then we could do both

dump($stuff)->someMethod();

and:

$object->someMethod(...dump($arg1, $arg2, $arg3));

imho: it would be a bit awkward to do

dump($foo, $bar, $object)->methodOnObject();

The goal is to dump some variables and make your application still work, kind of, without having to do too many keystrokes.

I really like what @hannesvdvreken proposed. I'll update this PR.

That's exactly what I proposed BTW :P Although I didn't think about the unpacking at the time, good thinking @hannesvdvreken !

Thank you @freekmurze.

Hello.

I think this is a BC break. Now we can not die(dump()) Anymore.
Exemple:

>[/tmp/toto] cat index.php
<?php

require __DIR__.'/vendor/autoload.php';

die(dump(new datetime()));
>[/tmp/toto] php -n index.php 
DateTime @1513766992 {#3
  date: 2017-12-20 11:49:52.615055 Europe/Berlin (+01:00)
}

Recoverable fatal error: Object of class DateTime could not be converted to string in /tmp/toto/index.php on line 5

Oh true. Before it would return null, and thus you would exit (or die) with null die(null).

This will require a small change to dump($stuff); die; instead.

At least you won't run die(dump()); in production, right ;-)

Yeah I know why it is not working anymore ;)
I don't know if this BC break is covered by our BC promise

where can we read more about that?

dump() is not covered by the BC policy, it's not part of any "API", it's just a temporary helper.
If you need BC, VarDumper::dump() should be used instead.

It's a shame. This PR has broken the dump function since it both outputs and returns now. This whole functionality should have been on a different function or something.

R.I.P. dump()