Add Label type

[TheRawMeatball]

Maybe potentially solves #103 and some similar issues.
Using these for RenderGraph nodes and slots is planned.

[Ratysz]

This looks way more complex than it needs to be.

Why not have separate derivable traits for labels of different types, instead of requiring an extra argument for the derive macro? E.g.,

#[derive(Debug, Hash, PartialEq, Eq, Clone, IntoLabel)]
#[label_type(StageLabel)]
enum Stages {
    SceneStage,
}

could be just

#[derive(Debug, Hash, PartialEq, Eq, Clone, StageLabel)]
enum Stages {
    SceneStage,
}

and Label<StageLabel> could then be reduced to

type BoxedStageLabel = Box<dyn StageLabel>;

(I'm not sure why does it have to be an Arc in the PR). Ghastly-named trait FullIntoLabel then disappears entirely, leaving only label: impl StageLabel or label: impl SystemLabel in it's place.

StageLabel and SystemLabel (and whichever else we might need) can share most of their machinery, you'll only need to implement PartialEq, Eq, and Hash on each dyn of them. Clone can also be arranged. See here for reference.

To prevent getting stuck beyond the bikeshedding event horizon of infinite potential, I would leave replacing all labels out of the PR, and instead implemented StageLabel (and maybe SystemLabel) on Into<Cow<'static, str>>. This should allow leaving them as is for now, and change them out slowly as we need - chances are we'll ditch stages entirely before such need arises anyway.

Unrelated, system labels don't seem to be plumbed in everywhere.

[alice-i-cecile]

Being able to refer to other systems by their type in some form rather than relying on always having to explicitly label your systems would be a really impressive win from an ergonomics perspective.

This would make the beginner experience a lot nicer and avoid really tedious boilerplate.

You'll usually only have one system for each function, and dependencies will usually be defined between systems in the same module.

I'm not super qualified on how you'd do so (default the label field using reflection?) but feel free to bug #ecs if you need mad science help and I can dig in.

Otherwise, Ratys's comments look solid.

[Ratysz]

We don't have a better way of doing this. Type name, or anything derived from just the signature, is about the only unambiguous thing we can get from a function without IntoSystem-ing it.

In any case, this is insufficient, because we may need multiple instances of the same type: not everything that's a system is a distinct function. It also muddles encapsulation of systems' labels and encapsulation of systems themselves: a plugin might not want to expose a system, to prevent multiple instances of it (potentially a safety concern), but would like to allow its users to order their systems relative to it.

This would make the beginner experience a lot nicer and avoid really tedious boilerplate.

I'll raise my point from Discord again: putting the schedule together is not something a user would be doing constantly. Barring pathological cases, any boilerplate we may introduce will stand out only in sterile demo code.

[Ratysz]

I still think that changing all the labels everywhere should be a separate PR: it's a lot of small, bikesheddable changes everywhere, it distracts from the implementation itself.

Tests should definitely not be touched: we continue to enable the simple stringly-typed labels for a reason.

[TheRawMeatball]

I still think that changing all the labels everywhere should be a separate PR: it's a lot of small, bikesheddable changes everywhere, it distracts from the implementation itself.

They're changes that need to be done eventually, why wait? They're already done

Tests should definitely not be touched: we continue to enable the simple stringly-typed labels for a reason.

That's a fair point though, I'll revert the changes in tests

[Ratysz]

They're changes that need to be done eventually, why wait? They're already done

Yes, I forgot to add "but they're already done, so never mind" - I don't think you should revert them now, but I haven't changed my opinion on them in general.

[Ratysz]

I've started experimenting on this branch, and some things keep nagging at me.

The derive macro is #[derive(ThingLabel)], but ThingLabel is a type, not a trait - this is not how derive is normally used. It's bound to confuse someone.

All methods using labels take impl Into<ThingLabel>. This can be minsconstrued as requiring to implement Into<ThingLabel> in order to use something as a label for a thing - which is what actually happens in the end, albeit indirectly. Deriving a ThingLabel is, again, not the first thing that would come to mind.

In my original prototype ThingLabel is a trait, which makes the derive macro a natural fit and allows the arguments to be impl ThingLabel (and &impl ThingLabel, which could probably be &dyn ThingLabel) instead. I'll see what it takes to adapt this branch to that approach, just so we have something to compare against.

[cart]

This looks good to me, but I agree with @Ratysz's assessment of the trait/derive.

We should also discuss removing the Eq constraint from labels (and changing DynEq to DynPartialEq). Its not strictly needed and would cut down on label declaration boilerplate. However (1) that might not work with @Ratysz 's proposed changes and (2) Eq is still correct "semantically", which imo is the main argument to include it.

I'm also about to push some (hopefully) non-contentious code style changes.

[cart]

I like to use the following order for imports:

• mod declarations
• public imports
• private imports
• code

[TheRawMeatball]

These labels are used in hashmaps which need Eq, so I don't think removing that is an option.

For the derives, I initally had an IntoLabel trait, and had its derive ask for a custom #[label_type] attribute, but @Ratysz changed my mind, so I'm not going to act on that yet.

[Ratysz]

I'll see what it takes to adapt this branch to that approach, just so we have something to compare against.

Here are the results: diff with Bevy master, diff with this branch. I'm biased, but I think this is cleaner.

Things that can be tweaked:

1. Label traits' guts are implemented via a plain macro. This is not as useful right now, but in the future we will likely have more kinds of different labels. The traits' definition itself can also be moved into the macro, but I opted to leave it out for ease of refactoring.
2. DynClone functionality is incorporated into the label traits themselves; this creates minor code duplication - although, seemingly less than when trying to lift it into a separate trait. I've opted to #[doc(hidden)] the dyn_clone().
3. type BoxedThingLabel = Box<dyn ThingLabel> is used internally everywhere (I think). It is not exported, because it bloats the API surface and is trivial.
4. Some impl ThingLabel arguments could be replaced with &dyn ThingLabel, like here (this one is done in order to get rid of an extra generic whenever these methods are used). I've opted to not do that yet, because it adds &s to user code; this would be in line with how std keys are used, however: take when inserting, borrow when querying.

[jakobhellermann]

This won't work for examples and doc tests if bevy_ecs is used in the main dependencies and bevy in the dev-dependencies.
Searching in the main deps first and otherwise in the dev-dependencies like here should work better.

[Ratysz]

This test passes, for what it's worth.

[jakobhellermann]

If bevy was added to the dev-dependencies it would fail. Or rather, the test would work but the other derives would fail.

[cart]

yeah its probably worth adopting that method here.

[cart]

@TheRawMeatball

These labels are used in hashmaps which need Eq, so I don't think removing that is an option.

But the user-defined label type isn't actually the type used in the hashmap (in the original impl we were discussing). We could remove the Eq impl in the user-defined type and still implement Eq on the wrapper type that is actually stored. I know this works because I implemented it before leaving the comment 😄

@Ratysz
I'm also partial to this impl. Definitely simpler in general. I also do like get_stage(label: &dyn StageLabel), not because of parity with std (afaik refs are only used in those interfaces because they work best generically. imo copy types shouldn't use refs in general). I like it because it makes calling the relevant methods less weird when it comes to generic type parameters.

[Ratysz]

So... What should we do then? &dyn ThingLabel where appropriate then pull my branch into this one?

[cart]

Hmm I'm guessing you don't have the ability to push commits here. I think the only important outcome is both authors getting credited. So if you create a new pr with @TheRawMeatball's commits in the history, then that works. Or alternatively @TheRawMeatball can apply your commits to this pr.

[cart]

And to be clear, i think we should only use &dyn ThingLabel when it makes the "calling ergonomics" situation more natural. We should accept impl ThingLabel wherever possible imo.

[YohDeadfall]

Or alternatively @TheRawMeatball can apply your commits to this pr.

It's also possible to open a PR to his repo and merge changes with rebase, so no merge commit will be in the history of this PR.

[Ratysz]

Something went very, very wrong during conflict resolution. The PR lives on as #1473.

[Ratysz]

1473 is now merged, closing.