3 ms·

Yes, but I don't think a deeper discussion about the flaws of array handling C is really going to illuminate anything here. The conclusions generally go in one

Yes, but I don't think a deeper discussion about the flaws of array handling C is really going to illuminate anything here. The conclusions generally go in one of three ways--either you choose to use a different language, choose to deal with C (with tools like static analyzers or instrumentation), or choose to make proposals to the C committee. Proper array types are not present in C and they're unlikely to be added at any point in the future, so if the conversation is "the array data and length need to be combined into a single semantic entity", then the conversation is no longer about C, but the starting point for choosing another language. The int a[static 6] syntax made it into the language because it's a small enough change that it's not disruptive to existing uses of C, but it still has some benefit (I've used it, I've seen its benefits).

WalterBright 4y ago
My proposal is backwards compatible and will not disrupt existing use.
- klodolph 4y ago
  Do you have a more complete write-up somewhere? At face value, it looks like something that wouldn’t make it into the C standard, because VLAs were too much for the standard to bear. It’s also unclear how multidimensional arrays would work—presumably, you would want that to be possible, and distinct from fat-pointer-to-fat-pointer-array.
  - WalterBright 4y ago
    No, that's all I got, although since it is lifted directly from D, you can get a complete treatment there. VLAs had a poor cost/benefit because they're just too awkward to use. 20 years experience with D shows that the [] syntax knocks it out of the park. Any combination of static/fat arrays can be made for multidimensionality. For example, [..][3] array of 3 fat pointers [3][..] fat pointer to 3 element array [3][3] array of 3 3-element arrays [..][..] fat pointer to array of 3 fat pointers etc.
    - klodolph 4y ago
      I guess what I would want is to be able to have a fat pointer to a multidimensional array, like I can do in Fortran, NumPy, etc. Why is the 1D case special, here? My other questions are how do you create one of these fat pointers, how do you get the length, etc. This sounds to me like VLAs, but with a bigger change to the language, but unable to handle multidimensional arrays. VLAs, for all their faults, at least fit into the language for users well enough that people accidentally use them all the time (not necessarily a good thing).
      - WalterBright 4y ago
        > a fat pointer to a multidimensional array T[3][4][..] a; > length a.length
thayne 4y ago
I really want C to have a slice/fat-pointer-array type, because C is the least common denominator for ABIs and any kind of FFI, and since it doesn't have something like that, it complicates FFI from languages that have a more sane way of handling arrays. I'd even be happy if the standard just included a macro like: #define ARRAY(T) struct { T *ptr, size_t len } Along with a few functions for working with such types. Although that would be kind of unwieldy to use in C, since you would need a typedef to actually use any specific types.
- uecker 4y ago
  I am relatively sure we will end up adding a fat pointer next round. So long, you can look at my experiments using a struct type here: https://github.com/uecker/noplate/ https://github.com/uecker/noplate/ The typedef thing will go away with C2X where you do this in place.

WalterBright 4y ago

My proposal is backwards compatible and will not disrupt existing use.

klodolph 4y ago
Do you have a more complete write-up somewhere? At face value, it looks like something that wouldn’t make it into the C standard, because VLAs were too much for the standard to bear. It’s also unclear how multidimensional arrays would work—presumably, you would want that to be possible, and distinct from fat-pointer-to-fat-pointer-array.
- WalterBright 4y ago
  No, that's all I got, although since it is lifted directly from D, you can get a complete treatment there. VLAs had a poor cost/benefit because they're just too awkward to use. 20 years experience with D shows that the [] syntax knocks it out of the park. Any combination of static/fat arrays can be made for multidimensionality. For example, [..][3] array of 3 fat pointers [3][..] fat pointer to 3 element array [3][3] array of 3 3-element arrays [..][..] fat pointer to array of 3 fat pointers etc.
  - klodolph 4y ago
    I guess what I would want is to be able to have a fat pointer to a multidimensional array, like I can do in Fortran, NumPy, etc. Why is the 1D case special, here? My other questions are how do you create one of these fat pointers, how do you get the length, etc. This sounds to me like VLAs, but with a bigger change to the language, but unable to handle multidimensional arrays. VLAs, for all their faults, at least fit into the language for users well enough that people accidentally use them all the time (not necessarily a good thing).
    - WalterBright 4y ago
      > a fat pointer to a multidimensional array T[3][4][..] a; > length a.length

thayne 4y ago

I really want C to have a slice/fat-pointer-array type, because C is the least common denominator for ABIs and any kind of FFI, and since it doesn't have something like that, it complicates FFI from languages that have a more sane way of handling arrays. I'd even be happy if the standard just included a macro like: #define ARRAY(T) struct { T *ptr, size_t len } Along with a few functions for working with such types. Although that would be kind of unwieldy to use in C, since you would need a typedef to actually use any specific types.

uecker 4y ago
I am relatively sure we will end up adding a fat pointer next round. So long, you can look at my experiments using a struct type here: https://github.com/uecker/noplate/ https://github.com/uecker/noplate/ The typedef thing will go away with C2X where you do this in place.