Remove `SystemId` and one-shot systems

[Freyja-moth]

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

SystemId was introduced by #8963 to allow users to run one off systems outside of the usual schedules. However since the introduction of observers the need for them has become increasingly obsolete to my mind.

The only advantage of registered systems over observers is that registered systems can: directly return a value (but only when using World), take owned data as input, and you can filter which ones you're using via queries.

Being able to return a value, while nice, doesn't feel any more useful for long term storage than simply making a change to the ecs that you were probably going to make down the line anyways.

Using owned inputs only really makes a difference if you're using constants, or if you're only using one system and the data can't be cloned.

pub struct Container(SystemId<Box<dyn Display>>);

pub struct SpecialInput(Box<dyn Display>);

fn run_containers(
    In(input): In<SpecialInput>,
    mut commands: Commands,
    containers: Query<&Container>,
) {
    for Container(system) in containers {
        // This won't work
        commands.run_system_with(system, input.0);
    }
    
    for Container(system) in containers {
        // This will
        commands.run_system_with(system, Box::new("Hello there"));
    }

    if let Ok(Container(system)) in containers.single() {
        // As will this
        commands.run_system_with(system, input.0);
    }
}

However I'm not convinced that these benefits justify the api space over simply using observers

What solution would you like?

I am in favour of removing SystemId and all of it's associated methods entirely, however I know @chescock has their own thoughts on keeping run_system_cached so I'll let them state their case.

Along with this I would suggest some method that allows observers to be selectively run.

pub struct Special;

pub struct PlayerEntity(Entity);

fn trigger(mut commands: Commands, special_observers: Query<Entity, (With<Observer>, With<Special)>, player: Res<PlayerEntity>) {
    let observers = special_observers
        .iter()
        .collect();

    commands.trigger_entities(Flee { entity: *player }, observers);
}

But this may want to be hidden in some way to prevent new users from getting confused

[alice-i-cecile]

@CorvusPrudens says:

let system_with_output = commands.register_system(|| 4);

let system_id = commands.register_system(move |world: &mut World| {
    // You _cannot_ peer at the output like this within an observer.
    // This is critical in cases where you need it.
    let output = world.run_system(system_with_output).unwrap();
    println!("wow, a number! {output}");
});

And unlike some of the other points, this is not something you could paper over.
It would necessarily represent a lost capability.

[Freyja-moth]

Could we not have a trigger_entity method on world that returns the output from the observer? I feel like that should be possible with a bit of wizardry.

[ItsDoot]

Consider:

• Observers have multicast behavior (multiple observers can run from a single trigger invocation)
• One-shot systems have unicast behavior (at most one system will be ran from a run_system invocation)

So for the cases where you won't ever need the multicast behavior, observers are just additional overhead. I could see a case being made to replace one-shot systems with a better scheduling infrastructure, but observers are a different class of function invocation than one-shot systems.