Const generics look very interesting to me, especially since i like the typestate pattern and const generics look like they could be an easy way to implement it
👏👏👏👏 nice presentation, really enjoyed the deep dive into consts and what they can offer at certain depth level. I mostly use it very basically but now I see that there are more stuff to learn about them.
Sure the AppendNull struct works correctly? I don't know whether alignment could not mess that up, I sure am not certain that a single u8 is never handled differently with alignment from a corresponding slice. I would certainly try to test/ assert that the resulting byte pattern for at least some tests (up to the total size of 64 bit) is the same as with manually adding a terminating null. Alternatively, I believe using repr(packed) provides stronger guarantees.
if you look at the book on data layout, the repr(C) guarantees that the alignement is 1 with the AppendNull struct as it is aligned with the biggest field alignement (so 1 here as [T] has the same alignement as T), and the algorithm that is used to calculate fields offset also guarantees that when all fields have the same alignement there is no padding. repr(C) also guarantees field ordering, something repr(packed) nor repr(Rust) guarantees. Sure you could use repr(C, packed) and be absolutely sure, but it is already well defined with just repr(C).
Yes but you would need to handle each pointer width. This approach works with a single statement using a bool condition, which is simpler in some regards.
Const generics look very interesting to me, especially since i like the typestate pattern and const generics look like they could be an easy way to implement it
I've implemented yet not published the crate called ctoption (compile-time option). They allow to do that.
👏👏👏👏 nice presentation, really enjoyed the deep dive into consts and what they can offer at certain depth level. I mostly use it very basically but now I see that there are more stuff to learn about them.
Sure the AppendNull struct works correctly? I don't know whether alignment could not mess that up, I sure am not certain that a single u8 is never handled differently with alignment from a corresponding slice.
I would certainly try to test/ assert that the resulting byte pattern for at least some tests (up to the total size of 64 bit) is the same as with manually adding a terminating null.
Alternatively, I believe using repr(packed) provides stronger guarantees.
if you look at the book on data layout, the repr(C) guarantees that the alignement is 1 with the AppendNull struct as it is aligned with the biggest field alignement (so 1 here as [T] has the same alignement as T), and the algorithm that is used to calculate fields offset also guarantees that when all fields have the same alignement there is no padding. repr(C) also guarantees field ordering, something repr(packed) nor repr(Rust) guarantees. Sure you could use repr(C, packed) and be absolutely sure, but it is already well defined with just repr(C).
16:18 Meta programming flashbacks (｡o_o｡)""
Catching up to C++ in this area.
Awesome!
The people yearn for dependent types…
how would that even work when rust is a completely type erased language?
Could the usize example be solved with a cfg directive?
Yes but you would need to handle each pointer width. This approach works with a single statement using a bool condition, which is simpler in some regards.