Null host shouldn't exist when a Custom host is present

[Marco-Farruggio]

Correct me if I'm wrong, but the whole idea of the Null host is that it should only exist if there are no other hosts for that compilation, so that each enum/type etc has atleast 1 member, the NullHost, however, the Null host can currently compile in, even if the Custom host is used, on a compilation target which cpal doesnt have a backend for, this seems counter-intuitive to me, and infact, in my mind, compiling for a target without any of cpals backends and then using a custom host to implement it themselves, seem to go hand in hand, this also could be quite an easy fix (I believe). Also, this means that it will always set the default host to Null, instead of Custom

This seems like a logical error to me, and a quick PR I can whip up.

[Marco-Farruggio]

Digging deeper...

impl Host {
// this only exists for impl_platform_host, which requires it
pub(crate) fn new() -> Result<Self, Error> {
Err(Error::new(ErrorKind::HostUnavailable))
}
}

shouldn't this be part of the HostTrait?

[LastExceed]

I'd even go a step further and question why we ever need a null host. Rust supports empty enum types just fine after all. The initial PRs unfortunately don't provide a design rationale (or any description at all for that matter):

• Add a "null" implementation for platforms that aren't supported #12
• Restore the null implementation and compile it every time #62

shouldn't this be part of the HostTrait?

Agreed. Could even use the Default trait for this

[Marco-Farruggio]

I couldn’t think of a reason either, but I assume it’s so that default_host() can always return a Host, which I do like, having to deal with an Option<>, can be annoying, but I also don’t like the Null host lol, I’m going to do some thinking, and open up a PR to rework this whole host thing cus I have some ideas I’d like to dabble with

[Marco-Farruggio]

Also, the Null host is littered with unimplemented!() in many places, I think as it’s meant to be a dummy host for compilation targets without an audio backend, it should simply return errors, and not panic at the least

[LastExceed]

I'm voting for removing the null backend outright. To keep default_host() infallible, we could simply refuse to build on unsupported platforms entirely. We do have explicit platform requirements after all

[roderickvd]

I'm voting for removing the null backend outright. To keep default_host() infallible, we could simply refuse to build on unsupported platforms entirely. We do have explicit platform requirements after all

I haven't fully thought it through, but I tend to agree with this.

Before committing to a decision, I wonder if we can come up with counter-examples why we would need it.

Also, the Null host is littered with unimplemented!() in many places, I think as it’s meant to be a dummy host for compilation targets without an audio backend, it should simply return errors, and not panic at the least

It's a relic, and I think that was its original intent. If it indeed is just to get it compiled, then it doesn't really matter if it panics or returns errors, because the code is never intended to run.

At one point in time I began working on a functional null host that serves like piping to or from /dev/null but I never opened a PR for it. Most systems allow to create dummy devices themselves, so not really a reason for cpal to have one.

[Marco-Farruggio]

If it indeed is just to get it compiled, then it doesn't really matter if it panics or returns errors, because the code is never intended to run.

(And)

I wonder if we can come up with counter-examples why we would need it.

I assumed its use case would be something like an app with a button like "test if my machine has audio", and clicking it would call default host default device and make a beep etc, or atleast try to, handling any errors gracefully, a panic here seems odd, because the code could very well get run

I think it would be a lot easier to simply return a real cpal Error, or infact just delete Null itself

[Marco-Farruggio]

Agreed. Could even use the Default trait for this

I thought that was a great idea too, I just started writing it up on a branch, until I realised, some host's initialization can fail (going through them, not actually as many as I would've expected interestingly), and Default explicitely returns Self, not option/result, so I'm going to add a fn new() -> Result<Self, Error>

[LastExceed]

how does that work? doesnt the macro require ::new() to be infallible too?

[Marco-Farruggio]

it just .expects() it to be infallible I believe