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


#1

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?


#2

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.


#3

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


#4

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


#5

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


#6

Cool, thank you for the update!