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

Allow identifiers to take arguments #5

Closed
Emoun opened this issue Apr 29, 2020 · 4 comments
Closed

Allow identifiers to take arguments #5

Emoun opened this issue Apr 29, 2020 · 4 comments
Labels
D-accepted A decision (D) has been made and the issue will be worked on I-feature This issue (I) regards a (potential) feature in the project T-accepted Triage (T): Initial review accepted issue/PR as valid

Comments

@Emoun
Copy link
Owner

Emoun commented Apr 29, 2020

Increase the flexibility of substitution by allowing identifiers to take "arguments" that change what is substituted.

Example:

#[duplicate(
  let_var( var_name );  [ let var_name = Default::default();]
)]
fn func(){
  let_var(some_name);
  let_var(some_other_name);
}

Will expand to:

fn func(){
  let some_name = Default::default();
  let some_other_name = Default::default();
}

This issue will manage the feature for the short syntax only. A later issue will manage the same for the verbose syntax.

@Emoun Emoun added D-discussion A decision (D) has not been made yet and is open to discussion I-feature This issue (I) regards a (potential) feature in the project T-accepted Triage (T): Initial review accepted issue/PR as valid labels Apr 29, 2020
@Emoun Emoun assigned Emoun and unassigned Emoun Apr 29, 2020
@Emoun
Copy link
Owner Author

Emoun commented Jun 11, 2020

The initial implementation will support the 3 default braces () [] {}. Later, we can add support for <> to allow the feature to be used in types.

@Emoun Emoun added D-accepted A decision (D) has been made and the issue will be worked on and removed D-discussion A decision (D) has not been made yet and is open to discussion labels Jun 11, 2020
@Emoun
Copy link
Owner Author

Emoun commented Jun 15, 2020

Update to the syntax:

#[duplicate(
  let_var( var_name );  [ let var_name = Default::default();]
)]
fn func(){
  let_var([some_name]);
  let_var([some_other_name]);
}

Arguments given to a substitution identifier must be wrapped in any kind of braces. This distinguishes one argument from the other.
Here is an example with multiple arguments to the same identifier:

#[duplicate(
  let_var( var_name method);  [ let var_name = MyTrait::method();]
)]
fn func(){
  let_var([some_name] [some_method]);
  let_var([some_other_name] [some_other_method]);
}

Which expands to:

fn func(){
  let some_name = MyTrait::some_method();
  let some_other_name = MyTrait::some_other_method();
}

Notice in the declaration of the identifier, the argument list is not separated by anything, just a list of identifiers.

@Emoun
Copy link
Owner Author

Emoun commented Jun 16, 2020

Update to the identifier argument invocation:

#[duplicate(
  let_var( var_name method);  [ let var_name = MyTrait::method();]
)]
fn func(){
  let_var([some_name], [some_method]);
  let_var([some_other_name] ,[some_other_method]);
}

When invoking a substitution identifer, the arguments must be separated by commas. This because rust will refuse to compile a list of groups (i.e. [some_name] [some_method] doesn't work, [some_name], [some_method] does.)

For now, the declaration of the identifier doesn't need commas. However, this may change in the future with a revision of the syntax.

@Emoun
Copy link
Owner Author

Emoun commented Jun 21, 2020

When declaring a substitution without arguments, they should be separated by commas. It's just confusing that you don't need a comma. Additionally, since all other rust code requires commas, it is muscle memory to add them, and causes confusion when duplicate fails because of their presence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-accepted A decision (D) has been made and the issue will be worked on I-feature This issue (I) regards a (potential) feature in the project T-accepted Triage (T): Initial review accepted issue/PR as valid
Projects
None yet
Development

No branches or pull requests

1 participant