On Thu, Apr 4, 2024, at 3:49 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/4/24 17:40, Vinicius Dias wrote:
>>> I like this concept, but instead of introducing a new syntax, have you
>>> considered leveraging attributes in the same way that PHP 8.3
>>> introduced #[Override]?
>>>
>>> #[Nonvariadic]
>>> function foo () {}
>>> foo(42); // warning: foo() expects exactly 0 arguments, 1 given
>>>
>>> I think the intent would be clearer and it would avoid introducing a new
>>> syntax.
>>>
>>
>> I agree that using an attribute would be better for this case.
>
> I disagree with an attribute being the right choice here. In contrast to
> #[\Override], this proposal changes the behavior for the *caller* of the
> function and likely also requires adjustments in child classes when
> newly introduced in a parent class or interface.
>
> Thus it is part of the function's API and thus should be part of the
> regular signature and not the attribute-based metadata.
>
> Best regards
> Tim Düsterhus
I would think following the pattern of dynamic properties would make the most
sense. Require an opt-in via attribute, with deprecation period. And possibly
just remove the functionality at some point in the future.
The core issue here IMO isn't the behavior itself, but the inconsistency.
C-implemented functions reject extra args. PHP-implemented functions ignore
them (modulo variadics). This is... a total mess that has bitten me more than
I want to admit. Normalizing it one way or the other would be a win.
--Larry Garfield
