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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
