When do change unstable feature to stable?

[k-nasa]

Now, async-std have many unstable function and module.
When do change unstable feature to stable?

[yoshuawuyts]

@k-nasa that's an excellent question! -- There's no concrete plan in place, but I think we can review it on a case by case basis. In general I'd think we could do the following:

• Stream combinators: we can probably stabilize most, if not all of these
  • We can probably stabilize more of streams as well. Probably the only things we'd need @stjepang to take a look at are FromStream / IntoStream since those have some rough edges.
• Print macros: we should probably remove all of these. They're not safe, and not very useful either.
• Pin submodule: we should remove this.
• Process submodule: the new runtime would resolve this. Probably keep this as unstable? We can also remove, and later decide to add back.

How does this sound? If you'd like to make PRs for this, I'd be happy to review. It'd be great to put out a new async-std release this month, and stabilizing things sounds like a great idea!

[k-nasa]

@yoshuawuyts

• I agree with the stream combinator. Almost stable.
• I think too print macro delete
• I think unnecessary re-export std module. So I think it should delete.

I'll submit remove macro and re-export std module. Please review!

[yoshuawuyts]

@k-nasa sounds great; will do!

[taiki-e]

@yoshuawuyts @k-nasa:

I have some concerns about traits stabilized in #719:

• Known issue of FromStream (StreamExt::collect does not preserve Send #639): Fixing this may require breaking changes.

• Other traits that use dyn trait need to consider similar issues to FromStream. (Extend, Sum, Product)

• (AFAIK) async-std's FusedStream does not work without specialization, unlike futures's FusedStream. And, currently, async-std doesn't provide support for specialization. So, I don't think this needs to be stabilized immediately.

• DoubleEndedStream does not use extension trait pattern, unlike existing traits. This is a small trait, but note that this may prevent providing more granular options in the future. (e.g., provide only traits without providing utilities. This is what futures and tokio currently do.)

These seem to be stabilized with little discussion in #719 and this issue. So, I suggest that we revert the stabilization of these traits (or all traits stabilized in #719. there may be more issues, given that I haven't spent much time looking for this...).

[skade]

@taiki-e thanks! I think these concerns should block.