17946, "stonea", "Make c_array interface more like Chapel arrays", "2021-06-18T18:46:44Z"
This is a spinoff from some comments on https://github.com/Cray/chapel-private/issues/2126 :
It would be nice if the following worked:
var a : c_array(c_float, N);
a = 1..N;
Currently it produces this error:
streamChpl.chpl:17: error: could not find a copy initializer ('init=') for type 'c_array(real(32),10)' from type 'range(int(64),bounded,false)'
$CHPL_HOME/modules/standard/CPtr.chpl:208: note: this candidate did not match: c_array.init=(other: c_array)
streamChpl.chpl:17: note: because actual argument #1 with type 'range(int(64),bounded,false)'
$CHPL_HOME/modules/standard/CPtr.chpl:208: note: is passed to formal 'other: c_array'
I got the following feedback from Brad (see the private Github issue for more details):
I suspect that we could support this easily by adding more assignment overloads for c_arrays. A question I'd want to wrestle with here is whether our goal with c_arrays is to make them only support the operations that such arrays support in C; or whether the goal is to make them support as much of Chapel's array interface as is appropriate (e.g., should I be able to write myCArray[3..] to refer to a slice of the C array? Or should that kind of nicety only be supported for Chapel arrays? (where maybe we'd have a way to "view" a C array as a Chapel array?)). I could probably argue either side of this issue and am not sure where I'd land offhand.
I'd argue that we should make c_array as convenient as possible. Does anyone else have thoughts?