Pre-RFC: A cleaner way to create an [u8 ; N]

Hello,

I would like to propose we have a better way of creating [u8 ; N] types, as these are very useful when dealing with FFI.

Context

I am trying to create a high-level wrapper around the python27-sys crate. This high-level library should make dealing with pythons reference counts automatic and help with common use-cases.

One of these use-cases is the defining of the module itself. To do this in C you would create a static structure as seen here: python reference.

I have tried find a few different ways of doing this in rust, all of which falls into one of these two categories:

  • Create the structure on the heap at runtime instead of on in the .rodata section. This could be done e.g. using lazy_static or creating the structure directly in the initialization function and then forgetting about it without calling the destructor.
  • Do stuff similar to &[b'f', b'o', b'o', 0] as *const u8 as *const i8.

While the first solution is mostly acceptable for my use-case, it is not so in all cases. The FFI might require a static struct with a specific name or there might be resources (or possibly security) constraints.

You can see my solution to the problem here. It could be improved a bit with macros, but they would not help the issue with writing each letter as a separate entity.

Proposal

To deal with this I think we should have a less ugly way of declaring static byte arrays.

  • We could have b"foo" be of type [u8 ; 3] instead of type &[u8].
  • We could re-introduce the bytes!() macro for this purpose.

Alternatively we could postpone this, as it could probably be solved by either compile-time functions or by procedural macros.

What do you think?

shep-home on #rust suggested that I make an RFC out of this, but I wanted to get some feedback before doing a pull request.

There is an accepted RFC that makes b"..." have type &[u8; N]. It hasn’t quite been implemented yet, unfortunately.

3 Likes

I see, thank you! In that case, never mind.

@Idolf It is implemented now, the relevant pull request was merged today.

Cool, thank you for the update!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.