Add a test to the CircularBuffer exercise to check if elements in the buffer are dropped when the buffer is dropped

Programming Rust
1

A common solution to this exercise is to use MaybeUninit<T> in the buffer. However, MaybeUninit<T> explicitly never calls Ts drop code.

A sound solution should drop elements in the buffer when it is dropped. This test checks for that.

2

See this PR: Add a test to the CircularBuffer exercise to check if elements in the buffer are dropped when the buffer is dropped by LarsKue · Pull Request #1842 · exercism/rust · GitHub

3

Hi, thanks for the post. Looks like a good addition. Could you provide a solution that passes the currect test suite but not your new test?

4

Sure, I added it to the PR.

1 Like
5

This is not exactly Rust related, but I saw an implementation in mentor request back in October on the powershell track somewhat related to this.

The student used a fixed size array filled with int to initialized the buffer when created new or after a clear, so it will all be filled out with 0 as default. Ultimately it doesnt clash with any of the tests in the suite, but I end up advice him to init it with null instead.

For me personally it feels “wrong” to have something to be empty but filled up with 0 instead of null, since there might be a legitimate reason or scenario when you want all 0. But I suppose in the end the point of the exercise was to learn about this data structure so I didn’t modify anything to the test suite.

6

Yeah, the Rust implementation of this exercise (almost) doesn’t have that problem. The API is generic, so the type checker won’t allow sentinel values like zero or null.

There is technically still a way to cheat, by adding a Default trait bound. I might add a test to ensure the buffer works with non-Default types as well.

7

Merged. Thanks @LarsKue !

Side note: circular-buffer is an exericse from problem-specifications. In general, tests should be upstreamed so other languages can add them too. But most languages don’t have manual memory management, so this test doesn’t apply generally. Therefore it’s appropriate to add the test to the Rust track specifically. I might check on the C++ track later if this test would be useful there.

8

The test could be added with the scenario tag of memory management (I’m not sure of the correct name etc). That would mean that tracks that have memory management can easily opt into it, but tracks that don’t can opt-out.

9

I don’t see a scenario related to memory management? (SENARIOS.txt) I suppose it could be created. But this test seems pretty difficult to represent in a way that other languages could easily generate their test cases from it… the logic is very bespoke for this one case.