Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can not make functions public with compose! #10

Closed
vitiral opened this issue Nov 19, 2017 · 10 comments
Closed

can not make functions public with compose! #10

vitiral opened this issue Nov 19, 2017 · 10 comments
Labels
2.0-wishlist This issue proposes breaking changes we'd like in a 2.0 release feature-request This issue is requesting new functionality

Comments

@vitiral
Copy link

vitiral commented Nov 19, 2017

I can't seem to make a function public

prop_compose! {
    pub fn arb_raw_name()(ref s in GEN_NAME_RE) -> String {                                                                                                                                                       
        s.to_string()                                                                                                                                                                                             
    }                                                                                                                                                                                                             
} 

has this error when compiled:

error: no rules expected the token `pub`
  --> src/test_name.rs:40:5
   |
40 |     pub fn arb_raw_name()(ref s in GEN_NAME_RE) -> String {
@vitiral vitiral changed the title public functions with compose! can not make functions public with compose! Nov 19, 2017
@vitiral
Copy link
Author

vitiral commented Nov 19, 2017

I got to hand it to you, this is one of the most well designed and documented libraries I've ever had the pleasure of working with. I'm about an hour in and the workarond is pretty obvious:

pub fn arb_raw_name() -> BoxedStrategy<String> {
    GEN_NAME_RE
        .prop_map(|s| s.to_string())
        .boxed()
}

Not that this isn't still a bug, but serious props to the entire architecture. I was using quickcheck, which I thought was quite excelent, but this is leagues beyond. Seriously well done.

@AltSysrq
Copy link
Collaborator

The macro predates the vis fragment specifier (and there's still no way to match modifiers in general), so it uses a hack like this:

proptest_compose! {
    [pub] fn foo()(v in prop::num::usize::ANY) -> usize {// ... 
    }
}

I will look into supporting vis as well so it "just works", probably after I get back from vacation.

@vitiral
Copy link
Author

vitiral commented Nov 20, 2017

it's not a super big emergency, I kind of like being explicit actually just figured you would appreciate the bug report

@AltSysrq
Copy link
Collaborator

It looks like the vis fragment specifier for macros is not yet stable, so supporting it will need to wait for now. (It would be possible to have a nightly-only feature, but it would be awkward to implement and client code would need to opt-in to it, which is more work than just using the brackets for the time being.)

@vitiral
Copy link
Author

vitiral commented Dec 9, 2017

I don't think a nightly-only feature is worth it. Thanks!

@AltSysrq AltSysrq added the feature-request This issue is requesting new functionality label Jan 27, 2018
@ornamentist
Copy link

New to Rust and proptest and have the same issue with the compose macro making only private functions. Also very impressed at the level of documentation and thought that has gone into proptest.

Can I ask whether the "GEN_NAME_RE" in the @vitiral workaround is a user-defined constant or a proptest constant? An example workaround function in context would be very useful.

AltSysrq added a commit that referenced this issue Apr 16, 2018
Since the question came up again in
#10
@AltSysrq
Copy link
Collaborator

the compose macro making only private functions

As I mentioned above, you can make them, just not with standard rust syntax since the macro can't match them. E.g., the following compiles:

#![allow(dead_code)]

#[macro_use] extern crate proptest;

mod one {
    prop_compose! {
        [pub] fn two_ints()(a in 0..10, b in 0..20) -> (i32, i32) {
            (a, b)
        }
    }
}

mod two {
    use super::one::two_ints;

    proptest! {
        // commented so it always gets compiled for this example
        //#[test]
        fn test_something(_a in two_ints()) {
            // ...
        }
    }
}

fn main() { }

Can I ask whether the "GEN_NAME_RE" … is a user-defined constant or a proptest constant?

It's user-defined. From other conversations I believe it is a string literal (i.e., a regex-based strategy).

@ornamentist
Copy link

Many thanks, that's exactly what I was looking for.

@Centril
Copy link
Collaborator

Centril commented Sep 13, 2018

Update: The vis matcher was stabilized in rust-lang/rust#53702 which hits stable in 1.30.

@AltSysrq AltSysrq added the 2.0-wishlist This issue proposes breaking changes we'd like in a 2.0 release label Oct 25, 2018
@AltSysrq
Copy link
Collaborator

AltSysrq commented Feb 5, 2019

As of 0.9.0, visibility modifiers can be used directly.

@AltSysrq AltSysrq closed this as completed Feb 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.0-wishlist This issue proposes breaking changes we'd like in a 2.0 release feature-request This issue is requesting new functionality
Projects
None yet
Development

No branches or pull requests

4 participants