Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68761
Return-Path: <smalyshev@sugarcrm.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 10056 invoked from network); 30 Aug 2013 21:50:45 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 30 Aug 2013 21:50:45 -0000
Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
X-PHP-List-Original-Sender: smalyshev@sugarcrm.com
X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6
Received: from [108.166.43.67] ([108.166.43.67:36885] helo=smtp67.ord1c.emailsrvr.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id E4/D1-00443-4B311225 for <internals@lists.php.net>; Fri, 30 Aug 2013 17:50:44 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C53E91487E4;
	Fri, 30 Aug 2013 17:50:41 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 81362148771;
	Fri, 30 Aug 2013 17:50:41 -0400 (EDT)
Message-ID: <522113B1.8000605@sugarcrm.com>
Date: Fri, 30 Aug 2013 14:50:41 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAF+90c_Ld1BAaj2kd+hhdNkcbj6Mar2EZSYPJaSFWqmV_tb=Xw@mail.gmail.com> <5220CEDE.8080600@sugarcrm.com> <CAF+90c_d4i0XC7d76_zfE6YLgEi_J2wv-F+kdtSCySsOSSw=9g@mail.gmail.com> <5220DA50.9020306@sugarcrm.com> <CAF+90c_iZqf0Di4hH49EW4ZYG=aHQ3Z2sU6aa6KU0cs5tjd6iQ@mail.gmail.com>
In-Reply-To: <CAF+90c_iZqf0Di4hH49EW4ZYG=aHQ3Z2sU6aa6KU0cs5tjd6iQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Not sure I get what you mean. All languages with argument unpacking
> allow this. It's not commonly needed, but there are uses for it and I

I mean this:

>>> a = [0,3]
>>> range(*a)
[0, 1, 2]

>>> a = [1]; b = [2]
>>> range(*a, *b)
  File "<stdin>", line 1
    range(*a, *b)
              ^
SyntaxError: invalid syntax

>>> a=[0]
>>> range(*a, 3)
  File "<stdin>", line 1
SyntaxError: only named arguments may follow *expression


> don't see a reason why one should explicitly disallow doing multiple
> unpacks.

Because it makes very hard to understand what's going on and makes no
sense semantically.

> As you can see, here two arguments are unpacked in one call.

This is very special use case to be hidden in library functions, I don't
think we need to have language syntax specially directed at that, at the
cost of making it overall more complex and hard to understand. I can see
what "add all those params at the end" syntax mean. However having
something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
what's going on at all and what is sent where.

> I tried to make sure that this does not "sneak in" but is mentioned
> prominently (it's half of the by-ref section). Anyway, as already
> mentioned in the RFC: Exceptions are how we deal with errors relating to
> Traversables in general. Yes, also in the engine. E.g. in the foreach
> implementation, if get_iterator fails an exception is thrown:
> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#4191

This is the only instance of exception in the engine, and it is very
unfortunate. However what is proposed in this RFC is using exception for
one special case of factual argument not matching function definition,
while exceptions are never used in any other case of the same problem.
This is inconsistent and wrong.

> If staying consistent with foreach is not wanted (or this is not

How calling a function can be consistent with foreach? Those are
different things. Calling a function should be consistent with all other
cases of calling a function.

> considered "consistent"), I'm also okay to turn that into a fatal error
> or into a warning where the argument will simply be passed without the
> reference-binding instead (like what we do when you pass a function call
> that returns by-value to a by-reference parameter. Though there it's
> actually just an E_STRICT.)

it should work like other instances of non-ref parameter (i.e. not a
variable and not a function returning by ref) passed to by-ref function.
Namely producing E_STRICT.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227