Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVr77jgnLtdRMbHGXDcGMk7U6nBnC4PY=GU+t6+W2qOt4g@mail.gmail.com>
References: <CALYT1Yo7+54PZrCQN35s1Vf+9QwfS1fau66vmQDH9SE=t2pFfw@mail.gmail.com>
 <CAPg3XxJEsBxhBCiBMGmroNQDnPsyTCvp3dLV2X-2t7_fiMcCxA@mail.gmail.com> <CAESVnVr77jgnLtdRMbHGXDcGMk7U6nBnC4PY=GU+t6+W2qOt4g@mail.gmail.com>
Date: Fri, 27 Oct 2017 12:17:22 +0100
Message-ID: <CAPg3Xx+eoCJqHRUY=87NO7CoeQ=JPoMoxCVDGS0gcwcqJ33Eag@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Sammy Kaye Powers <me@sammyk.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c076f6635e3f0055c857175"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Allow a trailing comma in function calls
From: petercowburn@gmail.com (Peter Cowburn)

--94eb2c076f6635e3f0055c857175
Content-Type: text/plain; charset="UTF-8"

On 24 October 2017 at 17:14, Sara Golemon <pollita@php.net> wrote:

> On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn <petercowburn@gmail.com>
> 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
>

--94eb2c076f6635e3f0055c857175--