All: I mentioned the possibility of pushing the error handling into the module code without reading Brad's reply first (responding oldest-to-newest). So it seems like we agree in general on that approach -- including keeping existing behavior for now.
Getting rid of all the cases where a return is required now is desirable. I think they are all covered by the "conditional-in-assignment" bug, so I have high confidence that I'll find a solution within the week. THH ________________________________________ From: Brad Chamberlain Sent: Wednesday, January 22, 2014 8:38 AM To: Vasily Litvinov; Tom Hildebrandt Cc: [email protected] Subject: RE: [Chapel-developers] Attention: Upcoming noisy changes in Chapel assignment. (fwd) > One way to take that out of the compiler might be to have a fall-back > function (or two) in the module that would be resolved to when the > actuals are non-lvalues or const lvalues. Those functions would throw a > compilerError(). Maybe proc =(in a, b) and proc =(const ref a, b) ? Personally, I don't think there's sufficient motivation to remove it from the compiler in this specific case. The compiler check is already needed for general ref arguments, and in the new patch, this is just a conditional if the function is an '=' (which, ultimately, we should extend to 'op=' as well). The new code (which you haven't seen -- it came out of my review of the first proposed patch) is cleaner than what we have *and* more accurate -- it catches cases with enums, records, and unions which were sneaking through before. All that said, I've asked Tom to maintain the current message for this patch and to consider any wording changes in subsequent patches to minimize the diff. > * Tom, you mention that proc = would still have a 'return' value in some > cases. This seems like an unfortunate complication, although I am sure > you have reasons for it. Are you envisioning this as a temporary > measure? Could you give an example? Speaking for Tom, it's a temporary measure, but one that I've requested we resolve before committing this change. I have said that I'm open to committing a change in which some =() rely on 'ref' and others rely on 'return' as a stopgap to get things moving in the right direction, but preferably not one in which some overloads *rely* on return which is where we are now. If we took the two-stage approach that I'm OK with, subsequent commits would gradually convert remaining =() overloads to not use 'return'. -Brad ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
