> Half of Vass's argument is cogent: const in implies a copy while const ref > does not.
I'm not disagreeing with that, but don't see what it has to do with the question at hand. I read Vass's reply as saying "you recently argued a point that was in opposition to a proposal I made on the basis of performance over purity, so I'm going to do the equivalent thing here (and put a smiley so that you'll have no idea whether I'm serious or just playing devil's advocate for fun)." If I'm missing a relationship that links the two scenarios beyond that, let me know. In my mind, the difference is that for this case, I think there's a clear story for getting the better performance from work that we've already slated for the coming year; for the other case, I haven't heard an argument yet (nor a compelling user scenario that runs afoul of the potential problem because of the choice). > It's a language design choice whether the values from a tuple may be used to > initialize the elements of an array. As > long as there in an array literal syntax, accepting a tuple literal in the > same context seems optional. I should've made this clearer in my original mail, but didn't: The current implementation isn't specific to initialization, it also includes assignment from tuples to arrays in general (where initialization is just one such case). > At such time as a move-constructor is provided, it would be possible to > efficiently "steal" the initial value of an array > from an array literal, whereas (it seems to me) an element-by-element copy > would be required if the initializer is a > tuple. I agree with all of this. I think Vass's efficiency argument was based primarily on the observation that creating a tuple value is cheaper in the current implementation than creating an array value. On the other side of that coin, our bulk copy optimizations probably only work between arrays and not from a tuple to an array (at present). But I'm not particularly interested in arguing this case on efficiency grounds, mostly because I anticipate that tuples are typically going to be modest in size. In favor of the current approach, one could argue that we should be able to assign from anything that's iterable to an array. That is, for an array A, if I can rewrite 'A = b' as 'for[all] (a,b) in zip(A,b)' then we should permit it. So, since homogenous tuples are iterable, we shouldn't outlaw the assignment from such a tuple to an array of equal size. On the other side of the argument, I think it's attractive to limit assignment to signatures of the form =(ref t, t) as much as possible* and I don't think we should support implicit coercions from tuples to arrays (such that the tuple could coerce into the RHS argument when the LHS is an array). (* = though I'm sure that I'll think of some exceptions to this rule of thumb that I'd champion of as soon as I hit send. Or if not, that Vass will gleefully point them out to me). Note that if we decided not to support array <- tuple assignment, it wouldn't need to prevent a motivated user or library from providing such an overload. I think if you forced me to choose tonight, I'd say "let's try to remove the explicit overloads supporting array <- tuple assignment and see what it would take to support it through the more general assignment-to-array procedure under the argument that tuples are iterable." > If we have to choose one or the other, then supporting the array literal and > deprecating the tuple literal is the clear > choice. As a feature however, being able to initialize an array from a tuple > is "pretty cool" in spite of its apparent > inefficiency. It would be too bad to give that up unless it is demonstrably > hard to support. I'm definitely not suggesting we deprecate array literals, nor that we have to choose one or the other. In any case, I feel pretty strongly that we should comb the tests for cases that rely on tuple literals for arrays for purely historical reasons and rewrite them to use array literals for clarity. Particularly for those cases that a curious user is likely to come across (like examples/). The testing I kicked off before leaving work tonight should identify those cases. -Brad ------------------------------------------------------------------------------ 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
