Is it suitable to require nightly in public crate?

help
1

I'm working on a new GUI library which is going to be published in the future. To make writing more comfortable and the macro more elegant, some unstable features are necessary. But almost all the crates I ever used only use stable features, so I don't know how to choose.
I want to simplify the code, but I am worried about potential safety problems. I wonder how others make the choice (I know Rocket, but heard there are some safety problems), and how to determine the safety and completion of an unstable feature (via tracking issues on GitHub).

The features I've used so far are impl_trait_in_assoc_type and return_position_impl_trait_in_trait.

Thanks.

2

This makes it sound to me like you use the nightly features only for convenience and not to implement the core functionality of your crate. In that case maybe you could make the nightly features opt-in, by hiding them behind a feature gate in your crate. I.e. a feature nightly which users can enable if they want to use the macro that is more elegant. Stable users would need to use the less-ergonomic, stable version of that macro instead.

1 Like
3

Uh, it is to implement the core functionality. For example:

impl Element for CustomElement {
    type Children<Str> = impl Structure;
    fn children<Str>(slot_structure: Str) -> Self::Children<Str> {
        build! {
            Div {
                prop1: todo!(),
                prop2: todo!(),
                @extend slot_structure;
                @extend structure_from_other_function();
            }
        }
    }
}

If I don't use impl_trait_in_assoc_type, I must figure out how to "give" user the type Self::Children<Str>. To do this, I must know what's the returning type of structure_from_other_function. This is just an example, there only will be more complex in practical case. Then, the code soon messed up.

Here I mean to make the macro syntax more elegant, which influences the implementation way.

Btw, how to determine which toolchain is used to compile the crate, nightly, beta or stable?

4

There are a few nightly-only crates on crates.io, but there are downsides:

  • Less than a third of Rust users use nightly, so you'll have fewer potential users.

  • Nightly gives no stability guarantees for the nightly features. They could change or be removed, breaking your crate.

I suggest check the tracking issue for the nightly features you plan to use to judge whether they may be stabilized soon as-is (in that case using nightly may be OK, because you'll be able to switch to stable when these features get stabilized). But some nightly features are stuck in limbo or are not even planned to ever stabilize. Using these will make your crate second-class forever.

7 Likes
5

Thanks. I think I should stay on stable.

6

For what its worth, these features should stabilize Soon™ (before year's end, probably). Stabilizing async fn in traits in 2023 | Inside Rust Blog

The standard practice is to use a cargo feature which you ask nightly users to enable.

7

Thanks a lot. But I only saw return_position_impl_trait_in_trait, excluding impl_trait_in_assoc_type, which is the key of the core API. But it doesn't matter. Now I know where to find these announcements. I'll be watching them.

8

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.