V0.4.0

[jamesmunns]

This is a pretty radical refactor.

On the plus side, this adds:

• const constructors of backing data, removing the need for macro initializers and static mut buffers
• Now is pseudo-generically sized with generic-array
• grants now automatically commit on drop
• commit/release methods are now on the grants, rather than on the producer/consumer
• For now, only offers interfaces if you split into a producer and consumer
• I haven't added grant max yet, I plan to implement these interfaces first

I still need to:

• Finish fixing tests
• Update docs
• probably one more sanity check of all the unsafe code
• re-implement grant methods
• Figure out a reasonable way to use in std, e.g. with a box
• Maybe implement an unsplit BBQueue instance

CC @jonas-schievink @korken89 @utaal @Disasm

[jamesmunns]

This has been published as 0.4.0-alpha1. If you want a good quick overview, check out this set of tests to see usage

[Disasm]

Will there be a way to use this library on top of static buffers?

[jamesmunns]

@Disasm you'll be able to to create a buffer at static scope, see these docs for details. You won't need to/be able to create one with a separate static &mut [u8] buffer anymore.

[Disasm]

Oh, missed that part, thanks! Are there any reasons to not use const fn new() for BBBuffer?

[jamesmunns]

Unfortunately, you cannot provide trait bounds on const functions in stable rust today, which is problematic for my usage of generic-array as a backing buffer, which requires that the size generic parameter have the ArrayLength<u8> trait bound. I use the same hack/workaround as the heapless crate to get around this, but it does require the slightly awkward BBBuffer( ConstBBBuffer::new() ) syntax.

[korken89]

Nice update!

Could you expand on why the runtime check for already split is needed? It is not quite clear to me.
It seems as if the buffer is implementing a singleton check (on the Producer and Consumer) within itself, rather than having users make a singleton object if they want one.
Is this perhaps the intended use-case?

[jamesmunns]

@korken89 I'm not of any other way to do this without runtime checking that:

1. Keeps the backing buffer alive, e.g. does not consume or move the buffer
2. Allows the backing structure to be immutable, preventing the need of unsafe to interact with it if it is stored at static scope

[jamesmunns]

I'm going to merge this, and start working on the v0.4.0 branch. I'll open up tracking issues for things that didn't make it in the 0.4.0 release, but could make it in 0.4.x releases.