Hello internals friends!

The RFC to allow a trailing comma in function calls is up for discussion:

https://wiki.php.net/rfc/trailing-comma-function-calls

Summary:

- Targets PHP 7.3
- The previous vote on this combined function calls & declarations in
the same vote (my bad!)
- This RFC affects function calls only, not declarations

Thanks,
Sammy Kaye Powers
sammyk.me

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 7 October 2017 at 19:34, Sammy Kaye Powers <[email protected]> wrote:

> Hello internals friends!
>
> The RFC to allow a trailing comma in function calls is up for discussion:
>
> https://wiki.php.net/rfc/trailing-comma-function-calls
>
> Summary:
>
> - Targets PHP 7.3
> - The previous vote on this combined function calls & declarations in
> the same vote (my bad!)
> - This RFC affects function calls only, not declarations
>

I know it's late in the game, but I have a quick question. This RFC
includes a couple of "Not really a function" functions (namely isset() and
unset()) that will also be able to have a trailing comma, but I'm failing
to find the discussion on including "not really a function" calls in this
RFC. Why were those specific non-functions choices included? Why only those?


> Thanks,
> Sammy Kaye Powers
> sammyk.me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn <[email protected]> wrote:
> I know it's late in the game, but I have a quick question. This RFC
> includes a couple of "Not really a function" functions (namely isset() and
> unset()) that will also be able to have a trailing comma, but I'm failing
> to find the discussion on including "not really a function" calls in this
> RFC. Why were those specific non-functions choices included? Why only those?
>
I'd guess because those are the only constructs which appear
function-like *and* exhibit variadic behavior.
empty/die/exit/print/require/include/require_once/include_once/__HALT_COMPILER
don't have a variadic mode so allowing trailing commas in them would
be pointless.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 24 October 2017 at 17:14, Sara Golemon <[email protected]> wrote:

> On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn <[email protected]>
> wrote:
> > I know it's late in the game, but I have a quick question. This RFC
> > includes a couple of "Not really a function" functions (namely isset()
> and
> > unset()) that will also be able to have a trailing comma, but I'm failing
> > to find the discussion on including "not really a function" calls in this
> > RFC. Why were those specific non-functions choices included? Why only
> those?
> >
> I'd guess because those are the only constructs which appear
> function-like *and* exhibit variadic behavior.
> empty/die/exit/print/require/include/require_once/include_
> once/__HALT_COMPILER
> don't have a variadic mode so allowing trailing commas in them would
> be pointless.
>

That's a fair point, then maybe we should consider declare() too? Also, I
know that "echo" is a "doesn't even look like a function" but can that be
considered as if we're changing any language constructs at all in this RFC,
then that might benefit too. Note, I'm just saying "consider" on purpose,
rather than suggesting any change to the RFC actually be made.


>
> -Sara
>
On Fri, Oct 27, 2017 at 7:17 AM, Peter Cowburn <[email protected]> wrote:
> On 24 October 2017 at 17:14, Sara Golemon <[email protected]> wrote:
>> I'd guess because those are the only constructs which appear
>> function-like *and* exhibit variadic behavior.
>>
>> empty/die/exit/print/require/include/require_once/include_once/__HALT_COMPILER
>> don't have a variadic mode so allowing trailing commas in them would
>> be pointless.
>
> That's a fair point, then maybe we should consider declare() too?
>
Perhaps, but since we've already entered voting, it'll have to be a
separate RFC at this point. That, or we reset and I don't think it's
worthwhile for declare because it's only got three possible values,
all of which can easily fit a single line.

> Also, I
> know that "echo" is a "doesn't even look like a function" but can that be
> considered as if we're changing any language constructs at all in this RFC,
> then that might benefit too. Note, I'm just saying "consider" on purpose,
> rather than suggesting any change to the RFC actually be made.
>
At a shot-from-the-hip guess, I'd assume that would introduce parser
ambiguity because of the lack of delimiting parenthesis.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login