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

[proptest-macro] add the ability to specify custom strategies #523

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

matthew-russo
Copy link
Member

replaces #478

Meta::NameValue(_) => {
if first_strategy_seen {
error.extend(quote_spanned! {
attr.span() => compile_error!("duplicate `#[strategy = ...]` definition");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may be worth saying the name of the parameter here for added clarity

snapshot_test!(custom_strategy {
fn foo(
#[strategy = 123] x: i32,
#[strategy = a + more()("complex") - expression!()] y: String,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is really cool that one can just assign a literal if needed. i'm curious about y here though, like what happens if an operator that cannot be used on string types is used? I guess that question may reduce down to, what happens if the strategies type does not match the type of the parameter, will the type error be relatively obvious for the user?

Copy link
Contributor

@rexmas rexmas Sep 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also do we expect argument types to ever use lifetimes or generics? what happens if someone tries to and should we test for that?

@rexmas rexmas closed this Sep 22, 2024
@rexmas rexmas reopened this Sep 22, 2024
Copy link
Contributor

@rexmas rexmas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

had a few questions but overall this looks great to me and happy to move forward with it! (assuming ci is 💚 after running)

also just to weigh in a comment from the original pr

I think for now, disallowing other attributes is safer from a backwards compatibility point of view - we don't lock ourselves into supporting something that is difficult later

i think i agree with taking a conservative/iterative stance here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants