Resolve variadic parameters as an empty array

[aldemeery]

consider these two classes

namespace App;

class Param { }

class Test
{
    protected $params = [];

    public function __construct(Param ...$params)
    {
        $this->params = $params;
    }
}

now when calling

app()->make(App\Test::class);

a ReflectionException will be thrown with a message Internal error: Failed to retrieve the default value

while doing a

$test = new App\Test();

without passing any arguments will work just fine.

On the other hand if the constructor was like this:

...
public function __construct($params = [])
...

calling

app()->make(App\Test::class);

will also work just fine.

So, I am suggesting to add the ability to resolve variadic parameters as empty arrays

PHP version: 7.2
Laravel version: 5.7.16 .

[imanghafoori1]

I do not get any errors.

[aldemeery]

I will update the issue with my php and laravel versions and how to reproduce the issue exactly

[koenhoeijmakers]

Whats the usecase for a class that is resolved by the containee that injects a variadic parameter?

[seriquynh]

I don't think making a constructor as you mentioned is a good idea.

[aldemeery]

@koenhoeijmakers I am working on a project where I have a RuleBag class, that acts as small container for Rule classes, and it looks something like this...

...
class RuleBag implements \ArrayAccess, \Countable, \IteratorAggregate
{
    protected $container = [];
    
    // Of course rules can be set using a setter, but the class can 
    // be initialized with some initial rules.
    public function __construct(Rule ...$rules)
    {
        $this->container = $rules;
    }

    ...
}

and then I am injecting this RuleBag into other classes...

...
class ProductValidator
{
    protected $rules;

    public function __construct(RuleBag $rules)
    {
        $this->rules = $rules;
    }
    
    ...
}

Now you obviously see that RuleBag can't be resolved because of the variadic parameter in its constructor, which led me to modify it to be like this...

...
class RuleBag implements \ArrayAccess, \Countable, \IteratorAggregate
{
    protected $container = [];
    
    public function __construct($rules = [])
    {
        // Manually validate that each element in the array is of type `Rule`
        $this->validateRules($rules);
        $this->container = $rules;
    }

    ...
}

[aldemeery]

@XuanQuynh Can you elaborate why you think so?

cause in my opinion if you can resolve a class with this constructor

...
public function __construct($params = []);
...

then it makes sense you can resolve a class with this constructor

...
public function __construct(Param ...$params);
...

because $params in both cases is an array with a default value of []

[seriquynh]

I don't really want to dive into your example. I see no benefits this case. In fact, you may prefer Param ...$params to $params = []. I think it's your coding style.

[aldemeery]

@XuanQuynh
Yes I know this is my coding style!
And I am no arguing if this has benefits or not!

I am just saying that if you can resolve $arr = [] because it has a default value, then it makes sense to be able to resolve Arr ...$arr because it has the SAME default value.

[seriquynh]

@aldemeery Ok. I see. For me, I just prefer the simpler way. If this is still helpful for you, you may persuade the core developers of Framework.

[Korko]

Sadly, this is not a Laravel bug (those fixable quickly here) but core php: https://3v4l.org/E7Ysf

[aldemeery]

@Korko thanks for the update. That's definitely something to consider.
Closing this since it's not specific to laravel.

[Tofandel]

@Korko You can check if it's isVariadic and infer that the default value is [] it's a specific case

See #43985