[Kim_Bruning]

Finally, after all these years, Named Arguments!

https://stitcher.io/blog/php-8-named-arguments

[EGreg]

Look, 10 years ago I tried — really tried — to get the PHP team to adopt it. I am glad they finally came around:

https://www.mail-archive.com/[e-mail]/msg4587...

Excerpt of the proposal:

So why am I saying all of this? Well, PHP up until 4 had a reputation for lots of bad coding style, spaghetti code, etc. With PHP 5 and better OOP, this reputation has lessened, especially with the great libraries out there (Zend Framework, Kohana, symfony, etc.) But there is still a problem. We (or at least I) would want PHP 6's reputation to be even better, and the reputation is largely based on how maintainable and cost-effective the code is, which is written by programmers actually using PHP. Blaming newbie programmers is one thing, and may even have some truth to it (PHP is simple - thus attracts newbies) but it's always good for a language to steer you in the right direction by default, and make it easier to write maintainable code.

PHP has a great opportunity to do this, by implementing a very simple change, turning all current PHP 5 code, and all code that will be written in the future, into maintainable code. Moreover, it won't break any existing code, like some other additions to PHP 6 might do. This one simple tweak will make PHP 6 code much more reusable and maintainable, just like namespace support will potentially make future PHP code more interoperable without having to write Artificial_Namespace_Class, like ZF and PEAR do.

[Kim_Bruning]

Thank you for your efforts back then.

And now you stand vindicated!

[EGreg]

Somehow one guy was really sure it will never happen:

https://www.mail-archive.com/[e-mail]/msg4804...

[zackmorris]

Thanks for that! The only error I see in their implementation is that we can't use variables for the name like:

  $name = 'foo';
  myFunction($name: 'bar');

Thankfully, we can still pass an array with the spread operator like:

  $name = 'foo';
  $array = [$name => 'bar'];
  myFunction(...$array);

I wonder if this would work:

  $name = 'foo';
  myFunction(...[$name => 'bar']);

Thankfully it's rather unlikely that someone would use a variable for the name anyway.

Where this will bite people is when they do meta programming with functions that process functions and function signatures.

Maybe I'm missing something, but I find this to be another tragically missed opportunity. It's just unnecessary friction where there didn't need to be any, which makes me sad. At least they can add variable name support someday, because it's easier to allow something restricted than restrict something that used to work. Hopefully there is a "good reason" for this oversight.

[tored]

It works https://3v4l.org/qY3os

[throw_m239339]

i'm not sure it's a good thing readability wise. I would have liked to see struct definitions + adhoc struct definitions and destructuring instead of that.

Some frameworks like Symfony relied too much on shoving unstructured array options as arguments though, so if it helps making API strictier...

[baby]

I don't understand why pretty much no language does that these days. I think the argument is that your IDE should do this, and it does in some cases, but still...

[chmod775]

You can get a much more powerful alternative for "free" if you support de-structuring assignments (in arguments).

JavaScript Example:

    function test({a,b,c}) {
        console.log(c,b,a)
    };
    
    test({
        a: 1,
        b: 2,
        c: 3
    });

If you have this there's really no need for named arguments anymore. If you add features to your de-structuring, your "named arguments" will have them too (things missing for JS specifically: optional objects, TS support to specify types for the destructured objects inline instead of repeating the entire thing).

[TekMol]

It is not more powerful. You cannot do this for example:

    function hello($name='Joe',$title='dear')
    {
        echo "Hello $title $name";
    }
    hello('Sue');

Try here: https://3v4l.org/6MZHh

With your object properties approach, you always have to use the variable "names".

[bmn__]

Mixing implicit positional and named parameters is a misfeature. The named parameters should have a distinct syntax like other systems do, e.g. :$ twigil.

[ptx]

Python, Kotlin and C# all support named arguments, and they're pretty popular languages. And also... there's Visual Basic.

[Okawari]

I guess you can add dart and maybe ruby and elixir if you accept that they treated as a map/keyword list on the receiving end of the function.

Edit: Ruby apparently made them first class citizens back in 2014. Ive been oblivious to this for years... wow.

[Can_Not]

Crystal supports named arguments.