Add "runtime" feature flag?

Some people want to use async-std for its channels, streams, and such without pulling in the actual runtime (networking driver and executor).

Perhaps we should consider introducing runtime feature flag, which would be enabled by default and would enable modules fs, net, os, process, and task modules.

We should then also pick a name for the core parts of async-std, perhaps we could have them behind a new core feature flag?

[yoshuawuyts]

@stjepang I like this idea a lot, and think that we should do it.

I don't think we need to add a "core" feature flag, because "core" is what you're left with if you disable "runtime". Besides: it wouldn't make sense to every enable "runtime", but not "core", so I'm not sure this would even make sense.

[yoshuawuyts]

Also I've been thinking of moving #238 forward, and it'd be interesting to consider what to name that feature. It'd be off-by-default, but would be a superset of "runtime".

and it'd be interesting to consider what to name that feature. It'd be off-by-default, but would be a superset of "runtime".

Maybe attributes? :)

[yoshuawuyts]

@stjepang oh I like that!

If the runtime feature flag is enabled by default, I think then we need to introduce another feature flag that describes everything else (perhaps core?).

The reason for that was discussed in #417, where we decided that if default-features is set to false and no features are enabled, then async-std should contain literally nothing.

So if someone wanted to use "core" parts of async-std, they'd have to specify that:

[dependencies]
async-std = { version = "1", default-features = false, features = ["core"] }

But perhaps "core" is not the best name for what we want here. We might want to reserve that name for parts of async-std that are usable in no_std environments.

[yoshuawuyts]

@stjepang I think we should not have another feature flag, and instead let the absence of "runtime" imply "core". If you want neither, it's probably time to remove async-std from the dep tree.

I think that would create a nice hierarchy, and a friendly user interface!

@yoshuawuyts I agree with you, but there's a compatibility hazard in that if we make something available by specifying { default-features = false, features = [] }, then we can't break those items further into feature flags.

So perhaps, just in case, we should introduce flag std that implies the existence of the standard library so that we can later on make it so that features = [] implies no_std environments?

I know @jamesmunns has liked this idea. In particular, we should consider making async-std usable from no_std environments in embedded systems. Anyways, I'm mostly rambling and thinking aloud here now.

[yoshuawuyts]

@stjepang okay sure, let's put it under "core" then. I haven't thought enough about the no_std usecase to have any meaningful opinions, in which case I agree it's best to be cautious.