New Issue: C Types: Bring into a single module, but where?

Notifications Issues
1

18013, "bradcray", "C Types: Bring into a single module, but where?", "2021-07-01T01:10:54Z"

Currently in Chapel's standard modules, what we might think of as core C types are scattered across different modules:

  • c_int is defined in SysCTypes
  • c_float is defined in SysBasic
  • c_ptr is defined in CPtr

The net result is that things are spread out in a nonintuitive way and several modules need to be used if a variety of C types need to be used.

There is a general consensus on the team to bring these together into a single module. The main questions are what that module should be called and what it should contain. Leading contenders are:

a CTypes module

This would define everything in SysCTypes today plus c_float, c_double, c_ptr(), c_void_ptr (assuming it doesn't go away with #18011), and c_array

a CInterop module (potentially using a different name)

This would define everything in the previous proposal plus other capabilities that felt closely related, like potentially those currently defined in CPtr: c_*alloc, c_mem*, etc.

in a submodule of a C module hierarchy

For example, imagine that C.Types contains everything in the CTypes proposal above, and that CMemory contains everything else in the CInterop proposal

in a module named C, in which the c_ prefixes would be dropped

The idea here would be that one could say C.int or C.ptr rather than c_int or c_ptr when using a fully qualified style. See issue #18012 for more on this idea.

something else?

I'm not putting voting options on this issue (yet) because I'd like to see more discussion on it first and to see how #18012 evolves.