Skip to content

Rename List::iter and friends to avoid auto-import conflicts #15088

Description

@MrGVSV

What problem does this solve or what need does it fill?

It's common to have users write their Bevy code in an IDE that supports auto-import. This is not always helpful as sometimes the wrong trait is pulled in.

A common example of this is accidentally importing List from bevy_reflect when autocompleting .iter().

There are other methods this can happen with too, such as with List::get, Array::is_empty, etc.

What solution would you like?

We should consider making the method names more specific to reflection and/or their trait.

For example, List::iter could become List::iter_elements, List::reflect_iter, or List::list_iter.

We'd probably want to do a similar thing for other traits like Array, Map, and Set.

The main thing we'd need to work out is what the new naming convention should be and which traits/methods need it.

What alternative(s) have you considered?

  • We could simply ignore this and just tell users to check their imports when they come across this problem
  • We could possibly force users to fully qualify methods on these traits by replacing self with dyn Trait (e.g. my_vec.iter() becomes List::iter(&my_vec))

Ideally, the auto-importers would simply avoid pulling in a trait when the method exists on either the type or the type's deref target. Or even just provide a way for us to hide/discourage certain traits from being auto-imported.

Additional context

See also #15002 for an example of this being an issue.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ReflectionRuntime information about typesC-UsabilityA targeted quality-of-life change that makes Bevy easier to useD-StraightforwardSimple bug fixes and API improvements, docs, test and examplesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!X-ContentiousThere are nontrivial implications that should be thought through

    Type

    No type

    Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions