Calling App::subscription causes previous subscriptions to be overwritten

[Lindenk]

Is your issue REALLY a bug?

• [x] My issue is indeed a bug!
• [x] I am not crazy! I will not fill out this form just to ask a question or request a feature. Pinky promise.

Is there an existing issue for this?

• [x] I have searched the existing issues.

Is this issue related to iced?

• [x] My hardware is compatible and my graphics drivers are up-to-date.

What happened?

Calling subscription more than once seems to drop all existing subscriptions silently instead of subscribing to both or producing an error.

Minimal example:

use iced::{Subscription, widget::text};

fn main() {
  iced::application("TestApp", App::update, App::view)
    .subscription(App::subscription_one)
    .subscription(App::subscription_two)
    .run()
    .unwrap()
}

#[derive(Default)]
struct App;

#[derive(Debug, Clone)]
enum Message {}

impl App {
  fn update(&mut self, msg: Message) {}
  fn view(&self) -> iced::Element<Message> {
    text("Testbug").into()
  }

  fn subscription_one(&self) -> Subscription<Message> {
    println!("Running subscription one");
    Subscription::none()
  }
  fn subscription_two(&self) -> Subscription<Message> {
    println!("Running subscription two");
    Subscription::none()
  }
}

Subscription one is never run, and no error is created if this is a limitation of iced

What is the expected behavior?

Both subscriptions are run independently

Version

crates.io release

Operating System

Linux

Do you have any log output?

[thorn132]

Only one subscription function is intended behavior, you're supposed to use Subscription::batch to return multiple.

[Lindenk]

Shouldn't it be an error to call subscription more than once then?

I would expect Subscription::batch to be called internally for multiple subscriptions if provided otherwise

[thorn132]

I know almost nothing about iced internals but it looks like generic type erasure on program::with_subscription means there isn't a way to know that .subscription() is being called on a Program which already has one, so emitting an error when that happens likely needs non-trivial changes.

[pml68]

It may be possible to collect subscriptions in a vec inside Application first and then call program::with_subscription in Application::run, but even then I assume hecrj rather make it an explicit choice to batch multiple subs.