The Gleeful Vass says "no more smileys for you, Brad." > I think it's attractive to limit assignment to signatures of the form =(ref > t, t) as much as possible*
On the principle, taking a general language feature and arbitrarily limiting it - does not count as "attractive" in my books. An example comes to my mind where Michael introduced an assignment operator in the compiler that takes an AST and assigns it into a GenRet, or some such. Separately, I like the idea of allowing anything iterable to be assigned to an array. I am fine supporting that as an actual assignment operation (=) or, picking Lydia's idea, as a library function, say proc store(dest:[], source). > I'm not convinced by that argument, nor the analogy. Move constructors > plus def-use analysis should support the ability to steal such initializing > array values. We should be as consistent "as possible" (quoting Brad). I am fine letting the assignment go (a) if nobody out there relies on it for performance, or (b) when the "should" above becomes "does", i.e. is actually implemented. Vass ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
