Closed kgv closed 4 years ago
Maybe? It looks nice but I'm curious about your workflow that you are asking for it. I only use stable. When I see people talk about using nightly, I get the impression that they are trying to minimize their nightly features and track removing them one-by-one. I'm unfamiliar with how much of a benefit this provides that someone would choose to add more of a reliance on nightly to get this.
If we do move forward with this, do people generally call the feature "nightly", "unstable", or a combination thereof? I sometimes name, suffix, or prefix features with "unstable" when they might change on the user but this is more than that, this also has a reliance on a special compiler version.
The question is - do you plan to provide this functionality after all the required features become stable? If so, then in my opinion it is worth giving users the opportunity to use this as early as possible. Then:
In my opinion:
nightly
feature;unstable
feature;
In this case, it’s both nightly
and unstable
The question is - do you plan to provide this functionality after all the required features become stable? If so, then in my opinion it is worth giving users the opportunity to use this as early as possible.
I have a slightly different philosophy. Being on the bleeding edge of nightly is for
I do not have a use case for either of these. Instead I'm focusing on being user-driven. assert_cmd and assert_fs do not need these features because they use the more complex API to get a report back on what failed. I know there are users beyond those two crates and if they have a use case for needing these things now, then I'd be open to adding it.
One example of a cost of this is that it complicates testing. iirc we are testing different feature combinations in the CI. With this, we'd have a feature combination we can't generally run and we'd have to special case the CI.
I understood your point. Then I think can close this issue.
Hi. What do you think adding
fn_traits
andunboxed_closures
features asunstable
crate feature; and implFn*
for predicates? This will allow functions that take predicates of the formFn*
take the following form:a.filter(eq(5))
insteada.filter(|some_variable| eq(5).eval(some_variable))
ora.filter(|some_variable| some_variable == 5)
see working example