Release v0.4.0

[dureuill]

• Read codebase again to look for further issues (docs, soundness, ...)
• Consider better names for BoxScope::new_typed and BoxScope::new_erased
• Populate CHANGELOG.md
• Increment version number in Cargo.toml
• Publish to crates.io
• Publish announcement article

Cc @steffahn: since your issues #7 and #8 as well as your macros proposal were instrumental to nolife v0.4, I think you might be interested in the release plan.

Also I'll be writing an announcement article that will mention you and your contribution, so if that's OK with you, I'll send you a draft by email before publication.

Cheers 😊

[steffahn]

Re new_typed, I think that should be called new again. Also erasing can now be done as a subsequent step, though also offering a single-step method for erasing seems not useless either. So that could be 3 methods new, erased and new_erased, the middle one being a BoxScope<T, F> -> BoxScope<T, dyn Future> conversion.

I also have further API improvement ideas, I think I'll write those up as a separate issue.

---

Re the article, I can sure take a look at that before publishing if you'd like.

[dureuill]

Re new_typed,

The idea for the UX here is that:

1. Most of the time people will want new_erased (at least while we cannot name opaque types), to easily tuck a BoxScope in a generic-less struct. We don't want people to be blocked with new not knowing that an erased version exists.
2. On the other hand, the erased version is doing more work that the concrete version, so we don't want that to be the default, especially when type alias impl trait in some position lands.

Hence the current stance of having both new_typed and new_erased, that pushes people towards reading their documentation and realize both options exist. The thing is I really don't like the typed naming.

I also have further API improvement ideas, I think I'll write those up as a separate issue.

With pleasure. Are these breaking changes, or backward compatible changes? If breaking, that might be a good reason to delay 0.4 as I don't want to release a 0.5 immediately afterwards.

Re the article, I can sure take a look at that before publishing if you'd like.

Thanks, I'll keep you updated once the draft is done. I'll do the other tasks first.

[steffahn]

With pleasure. Are these breaking changes, or backward compatible changes? If breaking, that might be a good reason to delay 0.4 as I don't want to release a 0.5 immediately afterwards.

Yes, I believe they would most likely include breaking changes. I've made an overview of my ideas in #15.

[dureuill]

in the end, I went for BoxScope::new and BoxScope::new_dyn. They feel like the obvious names. Things should be smoother once we get ATPIT.

I'm missing a re-read of the code and then I'll proceed with publication on crates.io.
I'll get to the announcement article afterwards