My concern with this patch's change to passByRef() is that flattening will pass large records by value. Which is exactly what our 'const' intent is intended to eliminate. Seems inconsistent to me.
> But your mention of 'const ref' and semantic grounds has got me > thinking... 'const' only means that the callee won't modify the argument, > not that the caller won't do so, so I'm not convinced that we can safely > r.v.f. 'const ref' arguments. In particular, the caller may still be > modifying its copy, and a sync var access may be used to force the callee > to see those updates. Brad, this reminds me of an off-list discussion we had, where you said that (a) such a scenario is not likely and (b) then the user shouldn't be using 'const'/'const ref'. If the callee is supposed to see the caller's updates to a 'const ref' formal, then the 'const ref' formal should not be marked with INTENT_FLAG_CONST. Because I'd like our compiler to treat/optimize as consts all things that are marked with INTENT_FLAG_CONST. As opposed to than checking INTENT_FLAG_CONST && !INTENT_FLAG_REF or some such. Because the latter would go against the intention of introducing INTENT_FLAG_CONST, to begin with. Vass ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
