feat(AztecMacro): Autogenerate constants for struct field slots for better note-getter options

[spalladino]

When writing a note getter, the dev needs to specify how to filter or sort based on the indices of each field. This is error prone, as a small change in a struct automatically breaks all note getters that depend on it if it changes the position of the fields.

We should somehow automatically generate constants (macros? new language feature?) for getting the index of a field within a struct, to be used in note getters.

struct MyStruct {
    foo: Field;
    bar: Field;
}

NoteGetterOptions::new()
            .select(MyStruct.foo.index, _foo)
            .select(MyStruct.bar.index, _bar)

Requested by @0xShaito from Wonderland

[Thunkar]

Is this the only use case for this feature @spalladino? I was discussing it with @sirasistant and @rahul-kothari and we found a pretty problematic footgun if implemented naively. Since we allow users to do things like this:

struct TrickyNote {
    a_bool: bool,
    another_bool: bool
}

impl Serialize<1> for TrickyNote {
    fn serialize(self) -> [Field; 1] {
        [self.a_bool as Field + (self.another_bool as Field) * 10]
    }
}

impl Deserialize<1> for TrickyNote {
    fn deserialize(fields: [Field; 1]) -> Self {
        Self {
            a_bool: fields[0] == 1,
            another_bool: fields[0] / 10 == 1
        }
    }
}

And NoteGetterOptions operates in "serialized world", we could have the following situation:

struct Storage {
    notes: Set<TrickyNote>
}

fn main() {
    // oh noes
    let what_to_look_for = "i_dont_know";
    let options = NoteGetterOptions::new().select(
        TrickyNote::get_index_for("what?"),
        what_to_look_for,
        Option::none()
    );
}

Granted it's a convoluted case, but it shows the disconnect between the struct shape and the serialized form. If this is the only usage of such a feature, I think we need a better solution.

[spalladino]

Yep, this is the only use case for this feature (that I know of).

Agree that with your scenario this is a potential footgun, but the current way of doing things is not good either. Maybe this is a hint that note serialization should be handled automatically by the system..?

[Thunkar]

Maybe this is a hint that note serialization should be handled automatically by the system..?

It would be pretty easy to create a canonical (de)serialization impl for notes via macro that ensures 1 struct field -> 1 serialization field, but it could be both less efficient and add a significant amount of "magic" to the platform...

[spalladino]

I'm not too familiar with Rust, but maybe this could be solved if we had a derive macro in Noir, such that we could derive(serializable) for notes, using a default implementation (either 1 struct to 1 field, or some form of packed serialization?).

Still, this doesn't solve the MyStruct.foo.index problem when the index in the serialization does not match the one in the struct. Perhaps we need to have a separate method get_index_of_field that needs to be implemented as part of the serializable trait for notes, or gets derived automatically?

[nventuro]

add a significant amount of "magic" to the platform...

As a new user this doesn't feel like magic: on the contrary, I'd greatly appreciate not having to deal with all of these details (until I absolutely have to). I'd compare this to how Solidity doesn't have you worry about how structs are passed in external calls, received, hashed, emitted in logs, etc.