Re: Pass by Reference
- Posted by jimcbrown (admin) Jan 16, 2015
- 1888 views
You are assuming that return 1,2,3 and a,b,c=f() has been accepted while I am assuming it has been rejected.
I'm only assuming they are still being discussed. Is there an official accept/reject committee I should know about? 
Actually, there is a dev team, but before outright rejecting anything we typically take a vote... (which hasn't happened yet afaik).
OTOH, features can still be discussed in the future, after a rejection... even if something is rejected the first time around, the additional discussion might lead to it being accepted the second time around.
I may sound impatient, but I know there are often compelling architectural reasons for not doing things. I'm trying to make sure people understand my motivations (not always easy, since we approach these things from different goals and backgrounds),
I'm glad you're making the effort (and I think you're quite good at it).
and writing like this is really not an optimal way to do things.
Erm, is there a better way to do it?
I still don't feel the benefits have been proved, or have been so vaguely described (or more often perhaps using you cannot when I think you can and therefore not counted) that I don't think I could even list them, at least not distinct from a still-{}-populated world. Admittedly my last post had a missing implied "if you adhere to this style, maybe we could have some useful compile-time messages" theme, sorry about that.
Well, dcuny was the one who pointed out that if we adhere to Lua-style multiple assignment, then we'd have some useful compile-time messages - so we'd fail faster (parser/compile time error instead of a run-time error or worst of all, a potentially hard to catch logic bug), and perhaps it'd be easier on the coder (less time required to scrutinize all those desequencing calls to make sure no one is doing anything silly).
I did point out that it's possible to get the same benefit in a different way, but, OTOH I find dcuny to be very persuasive...
Plus, the fact there would be two semantically different forms of multiple assignment, that might happen to be implemented identically under the hood, might just be a little too difficult for me.
I'm going to keep on being pedantic about not calling de-sequencing different from multiple assignments.
If it were added, multiple assignment would probably be implemented under the hood in OE this way - via desequencing - so the only difference would need to be at the parser level. There's still complications with call_func() perhaps, but see below..
I've only just grasped the full extent of the call_func() issue and yes that gets horribly messy because it has to drag all this stuff out of the parser and right into the runtime/translator, for very little benefit.
If desequencing simply mandated that the LHS and the RHS must have the same number of elements, or else it's a run-time error, then simply using desequencing with call_func() would be able to catch most of the errors that the parser's multiple assignment scanner would. Hmm.
