Chapel: Should we deprecate c_string?

[mppf]

Several of us are thinking it would be wise to deprecate c_string and instead rely on c_ptr(c_char) and related types. Since c_string actually refers to const char*, presumably it would be necessary to first solve #14214 to allow one to write something like c_ptr_const(c_char).

Why deprecate c_string ?

• C doesn't really have strings
• It exists for historical reasons
• It causes confusion about the ownership of c_string (e.g. one might assume that myString.c_str() should be freed, when in fact it just aliases the data)

[bradcray]

I think this issue should be retitled "How soon can we..." :D

[e-kayrakli]

Just as a note, on an offline discussion @bradcray suggested that we can add a --warn-unstable warning in 1.21 if we don't get to deprecate the c_string type altogether.

[dlongnecke-cray]

I think that a good start for this is to deprecate support for c_string in our interop story. This would be quite feasible to do now that we have support for exporting both the string and bytes type.

[ben-albrecht]

To help port c_string codes to c_ptr(c_char), there ought to be an easy way to get a c_ptr(c_char) from a Chapel string like we have for string.c_str() to get a c_string... or does something like this already exist?

[mppf]

I suspect we would simply have string.c_str() return c_ptr(c_char).

Also, the issue description talks about c_ptr_const - so maybe string.c_str() would return c_ptr_const. At the very least that would indicate that users aren't supposed to modify the elements (even though they technically can, in the C type system...)

[mppf]

Or, maybe we would a method with a new name, like string.ptr or string.c_ptr or something.

[e-kayrakli]

I suspect we would simply have string.c_str() return c_ptr(c_char)

Possibly. It may get a bit too tangled up and may require some effort, though.

At times I wonder whether we can have c_ptrTo(myString) return the buffer pointer for strings. I am not sure whether we'd lose anything by not being able to get the address of the string record, though.

[mppf]

@e-kayrakli - I wouldn't like that for the same reasons I don't like c_ptr(someArray) returning a pointer to the first element. (see #16135). But it would be fine to separate the concerns into 2 different functions.