On Fri, Aug 30, 2013 at 11:50 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote: > > 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.
Consistent with Traversable error handling. But don't want to argue that, as I do agree with you that adding the exception there may not be a good idea. > 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. "Other instances" do everything ranging from fatal error (not a variable) over warning (zend_call_function) to E_STRICT (a function returning by-value). I suggested a warning because I had the general impression that we're trying to be more strict about by-reference passing. But if you're saying that E_STRICT is the right choice here, then lets go with that. I adjusted the RFC/implementation to use E_STRICT instead, see: https://wiki.php.net/rfc/argument_unpacking#by-reference_passing >>> 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 > I wasn't aware that Python had such restrictions. I just checked and found out that Ruby also had this restriction, but it was *removed* in version 1.9.1. I couldn't find anything more specific on why they did it though (how Ruby does language development is a mystery to me. I can't even find docs...) The ECMAScript Harmony proposal does not seem to have this restriction. I also tried this in CoffeeScript, which also does not have the restriction. > > 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. It's possible to use nearly *any* feature in some totally convoluted way that nobody can understand. The main usage of the proposed syntax will be just fn(...$args) or fn($some, $fixed, $arguments, ...$args). In rare cases it will be fn(...$args1, ...$args2) [the bind example]. That's what you'll see in code. fn(...$args, $fixed) does not usually make sense, but if it does for once, why do we need to forbid it? If it doesn't make sense, people just won't use it, so you won't see it, so you won't have to figure out what it means. If it does make sense, then understanding it should be trivial. Of course, maybe my logic is flawed because I give too much credit to programmers and assume that they will employ features when reasonable and not when "hey, why don't I go put a ... in here!" Anyway, I don't think having a trailing fixed argument is *that* absurd. A pretty pointless example off the top of my head would be $this->query($query . ' LIMIT ?', ...$params, $limit), i.e. just adding another bound param to a set of existing ones. I don't really insist on allowing the trailing normal args, because I don't think they would be useful particularly often, but I just fail to see what we gain by forbidding them. Thanks, Nikita
