Reflect Struct QOL

[Diddykonga]

Objective / Solution

Add methods for additional ways to get field info on Struct:

Struct::index_of( &self, field: &dyn PartialReflect ) -> Option<usize>
Struct::index_by_name( &self, name: &str ) -> Option<usize> // Rename Migration: `index_of` -> `index_by_name`
Struct::name_of( &self, field: &dyn PartialReflect ) -> Option<&str>
Struct::name_at( &self, index: usize ) -> Option<usize>

Change FieldIter to return an tuple over the names/fields and impl IntoIterator for &dyn Struct for ergonomics.

let struct = MyStruct.reflect_ref();
for (name: &str, field: &dyn PartialReflect) in struct {
    // Do stuff...
}

Split From/Merge After: #22702

Testing

Migrations:
DynamicStruct::index_of(name) -> Struct::index_by_name(name)

Showcase

Click to view showcase

let struct = MyStruct.reflect_ref();
for (name: &str, field: &dyn PartialReflect) in struct {
    // Do stuff...
}

[alice-i-cecile]

Nit: you can probably clean this up by using ? out of the reflect_partial_eq.

[alice-i-cecile]

Same comment as above.

[alice-i-cecile]

This change needs a simple migration guide.

[alice-i-cecile]

Needs a small migration guide, and your other PR merged, but I like these changes. Particularly the iterator change to also include the names!

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[MrGVSV]

I'm not sure I agree with Struct::index_of and Struct::name_of as they currently stand (i.e. taking in a &dyn PartialReflect). But I do like the other ones!

[MrGVSV]

As mentioned in this comment, I'm still not fully sold on this behavior.

To summarize my thoughts, I believe this behavior (i.e. where a field from one struct returns None on a field of another struct of the same type) may be too unintuitive.

I'm on board with index_by_name (though I think it should be renamed to index_of) and name_at, but index_of (in its current form) and name_of seem too situational and easy to mess up.

I'm willing to change my mind if people feel strongly that this is useful/necessary, though.

[MrGVSV]

We should probably document that this only checks the address of the pointer. And because of this, the method will return None if it's given a reference to the same field from a different struct of the same type or if the field is not the original (i.e. it's a clone of the original).

As mentioned in my comment here, I do think that the address equality is a limitation of the current implementation. Therefore, it may not really belong in the documentation (in case users choose to manually implement it another way that can guarantee it works across struct instances and clones). However, the default implementation from the derive macro is going to be the most common, so I think it's definitely worth noting.

[Diddykonga]

This behaviour, during the split, was changed to rely upon PartialReflect::reflect_partial_eq, this comment seems assume its still using the previous core::ptr::addr_eq impl? Not sure how much of this coment chain applies with the change.

[MrGVSV]

Oh lol sorry yeah I just assumed it was a direct split and didn't actually check it was changed. My apologies!

However I think the same critique still applies: unless you’re using the same struct or struct with equivalent field value, this will return None. And now this may also return the incorrect Some value in the case that two fields have the same value.

[Diddykonga]

That's fair, I think both approaches have a downside, we could provide both? but that feels a little meh
name_of/name_of_field + name_at_addr.

[MrGVSV]

One idea for getting around the limitations I mention here, is to instead make name_of and friends return a Result with a potential error of like NameOfError::NonUniqueFieldType. And then return that error if the struct contains two of the same type field.

But I don't love that idea as it still is super limiting (just not as much).

[MrGVSV]

Another option that I think would work better is to provide a low-level API for working with struct field pointers and addresses directly. Then you could do something like:

let api = TheApi::from(&my_struct);
let field: NamedField = api.field_at_addr(&my_struct.field).unwrap();
let name = field.name();

In fact, renaming Struct::name_of to Struct::name_at_addr or something would probably be an okay compromise. But I still also don't know if this sort of low level API belongs in Struct (of course, the benefit is that we don't have to go through get_represented_type_info).