Impl `Fn*` for predicates as unstable feature

[kgv]

Hi. What do you think adding fn_traits and unboxed_closures features as unstable crate feature; and impl Fn* for predicates? This will allow functions that take predicates of the form Fn* take the following form: a.filter(eq(5)) instead a.filter(|some_variable| eq(5).eval(some_variable)) or a.filter(|some_variable| some_variable == 5)

see working example

[epage]

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.

[kgv]

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:

• users will be ready for the fact that they will be given in the future (for example, providing similar features in their subprojects),
• users will be able to leave feedback experience using this feature.

In my opinion:

• if it requires a nightly compiler - it have to be hidden behind nightly feature;
• if it can be changed in the future - it have to be hidden behind unstable feature; In this case, it’s both nightly and unstable

[epage]

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

• Working around showstoppers
• Testing and providing feedback on the features.

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.

[kgv]

I understood your point. Then I think can close this issue.