Ben

I put this together: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0a4172aa0c5df1ca06113d5fa18cb279 This is the first stages of a macro: ```rust use frunk::hlist; #[frunk::hl_build] struct ListConstructed { #[hl_field] field1: u8, #[hl_field] field2: String, user_defined: i32, } fn...

Progress report: ```rust use frunk::{hlist::Plucker, HList}; #[derive(Debug)] #[hl_build_macro::hl_build] pub struct ReferenceStruct { #[hl_field] field0: u8, #[hl_field] field1: bool, field2: f32, } pub fn demo_use() { let list = frunk::hlist!(true, 3u8,...

I'm trying to encapsulate behavior specification at the type-level. In my specific case, we have zero-sized-types, and what can be done is defined by the impls on these types. From...

Sure thing. I'll put something together to illustrate the difference in more detail. > Apologies if I'm being slow here It's on me. Perhaps the problem I'm solving is a...

ah yes, there is a bit of a mix up there. Inside the esp32 hal crate, the IO struct (input output) looks like [this](https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/src/gpio.rs#L1293): ```rust /// General Purpose Input/Output driver...

On point 1: Where iteration semantics are valuable, the HCons methods such as map are useful, but that's a niche case. The feature that I am ultimately hoping for is...

to provide a real-world example of what I have in mind, consider this code: ```rust let usb = USB::new( peripherals.USB0, io.pins.gpio18, io.pins.gpio19, io.pins.gpio20, &mut system.peripheral_clock_control, ); ``` This code could...

...with a little bit of help from chatGPT, I ended up with this: ```rust use frunk::hlist::Plucker; struct Mode; struct GpioPin { _mode: PhantomData, } impl GpioPin { fn new() ->...

Glad you like the solution! this is, in fact, intended to be an upstream commit to resolve partial-move issues when managing gpio pins for esp32 microcontrollers. You can see the...

Original comment: https://github.com/massalabs/massa/pull/3489#discussion_r1141961674