irc

(6:10:29 PM) fred: nikic: my guesses would be performance, us generally disliking references
  (they're banned in hack), it makes it harder to reason about the body - and socially, we
  have a fairly low bar for 'this should be a real closure instead for readability' so it
  doesn't actually matter
(6:10:38 PM) fred: (to us)
(6:10:51 PM) sdoowpilihp left the room (quit: Quit: My Mac has gone to sleep. ZZZzzz…).
(6:11:36 PM) fred: nikic: oh, for the actual lambda parameter?
(6:11:54 PM) fred: rather than other stuff that's used in it?
(6:12:06 PM) nikic: fred: nah, referring to the used stuff
(6:12:43 PM) nikic: but yeah, me not being a particular fan of references either, that sounds
  very reasonable to me :)
(6:13:50 PM) tester [5265d776@gateway/web/freenode/ip.82.101.215.118] entered the room.
(6:13:50 PM) fred: if they were byref, it'd be /very/ hard to know anything about the types of
  those locals after the lambda is created - and would also mean they couldn't just be cleared
  when the scope goes
(6:14:06 PM) tester left the room (quit: Client Quit).
(6:15:48 PM) fred: nikic: there's also that unless you explicitly make them referencesi n PHP
  closures, they're byval
(6:16:28 PM) fred: '$x ==> $x + $y' is function($x) use ($y), not use (&$y).
(6:16:44 PM) fred: feels like it would be consistent for one syntax to be automatically byref,
  one not
(6:16:47 PM) ihabunek left the room (quit: Quit: Connection closed for inactivity).
(6:16:51 PM) fred: *inconsitent
(6:16:51 PM) nikic: fred: most other languages seem to be using bindings that are even stronger
  than references - where the variable in the closure and outside it are literally the same.
  (In PHP that would mainly show through the way =& reference rebinding works)
(6:17:52 PM) fred: personally it's more important that a language is consistent internally,
  rather than consistent with other languages
(6:17:56 PM) fred: (yeah, I picked the wrong language...)
(6:17:58 PM) nikic: agree
(6:21:00 PM) nikic: fred: what I find a bit concerning is that attempts to change a by-value
  bound variable in a closure will just change the local copy rather than generate an error.
  So if people try to modify bound variables (based on expectations from elsewhere), the code
  will still "work", but silently discard the changes
(6:22:24 PM) fred: nikic: same is true for $x = function ...
(6:22:39 PM) fred: seems more surprising for it to sometimes work sometimes not
(6:25:31 PM) jwatzman|work [~jwatzman@facebook/hhvm/jwatzman] entered the room.
(6:25:31 PM) mode (+o jwatzman|work) by ChanServ
(6:26:29 PM) nikic: fred: yeah, sure, the same applies to the normal closure syntax (though there
  you need to be explicit anyway)
(6:28:08 PM) fred: nah, explicit would be C++-style use (=$x, &$y) :p
(6:28:16 PM) jwatzman|work: nikic: fred says you're interested why we did short lambdas by-val.
  i can poke elgenie to see if there's a more subtle reason, but my understanding is that 1) they
  are less confusing -- the typical JS lambda example is often immediately followed by "well that
  doesn't actually work", but more importantly
(6:28:28 PM) dsereni left the room (quit: Read error: Connection reset by peer).
(6:28:48 PM) jwatzman|work: nikic: 2) having any references anywhere absolutely destroys perf,
  since the JIT can't make a whole lot of assumptions it likes to make, particularly around types;
  they also create another layer of indirection, and are generally hard to optimize
(6:28:55 PM) nikic: fred: as usual in php, it's explicit-ish :)
(6:29:09 PM) jwatzman|work: the JIT angle doesn't affect PHP *right now* perhaps, but references
defeat tons of optimizations (unboxing!) that PHP might want to do in the future
(6:29:17 PM) nn-|em [~nn-|em@st0519.nas821.p-tokyo.nttpc.ne.jp] entered the room.
(6:29:41 PM) jwatzman|work: also, unlike C++/JS, the semantics of refs in PHP are absolutely
  impressively disgusting
(6:30:00 PM) paulbiss: (also: n.b. short lambdas were originally a hack feature, and hack doesn't
  have references, or at least pretends they don't exist)
(6:31:53 PM) nikic: jwatzman|work: thanks
(6:32:10 PM) nikic: is it okay to share chatlogs from here?
(6:32:30 PM) sdoowpilihp [~sdoowpili@unaffiliated/sdoowpilihp] entered the room.
(6:32:57 PM) jwatzman|work: nikic: hm, might be better if you clean up a little bit? Internals
  seems really sensitive to "zomg facebook is taking over and telling us what we have to do run
  away run away"
(6:33:48 PM) sdoowpilihp left the room (quit: Client Quit).
(6:34:04 PM) nikic: jwatzman|work: oh, not for internals. I'm not crazy enough to involve
  internals in design discussions
(6:34:11 PM) jwatzman|work: lol, wfm then
(6:34:36 PM) nikic: Usually it's better to have a finished proposal for internals and then let the
  discussion center around whether to use ==> or ~> for the symbol...
(6:35:39 PM) jwatzman|work: nikic: *nod* -- we were just noting here, if you use the Hack semantics,
  it would be sad to use a different operator since there really isn't a compelling reason to go
  either way  -- but if you end up doing by-ref, it would be even more sad to pick the same
  operator, and it would mean two different things in two closely related languages