Feature request: an equivalent of "char buffer[64];" in a struct

[certik]

Right now if you do:

@dataclass
class some_struct:
    buffer: i8[64]

It will produce an array with a descriptor. But rather, we need it to produce char buffer[64], that is, 64 bytes of memory. It could be that we can use a descriptor by default, but if we do:

@ccallable
@dataclass
class some_struct:
    buffer: i8[64]

Then it would use the array directly.

[czgdp1807]

For both C and LLVM backends, correct? And specifically for i8 type?

[certik]

Yes, I would always do it for the LLVM backend to ensure the design is good. This we also need for the C backend. Yes, we need it for i8, and if we needed larger ones later, I think we could "emulate" them using i8.

[certik]

This is now a pretty high priority, we need to figure out a fix.

[czgdp1807]

The underlying issue is #1350. If we figure out a decent protocol then solving this issue is a by-product.

[certik]

The issue #1350 is general, and we need to figure out a solution eventually.

In the meantime to unblock us, this issue is actually quite simple. Regular struct I think should not be BindC and we should have the freedom to rearrange or represent members (arrays) any way we like. In this particular case, when interoperability with C is needed, we should declare it as:

@ccallable
@dataclass
class some_struct:
    buffer: i8[64]

And then LPython creates all members, such as buffer, as BindC in ASR. This then in return prescribes that it must be represented by a pointer, and in this case the memory is in the struct itself, 64 bytes, just like in C.

[czgdp1807]

Makes sense. Will do so, once I come back from vacation.