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

Implicit module name duplication #7

Closed
Emoun opened this issue May 28, 2020 · 4 comments
Closed

Implicit module name duplication #7

Emoun opened this issue May 28, 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 May 28, 2020

Since procedural macros will soon support hygiene, it would be appropriate to implement implicit module name duplication.

if duplicate is applied to a module, the user is currently required to make sure that the module has a unique name for every duplicate. This is tedious and must be done every time. To improve the user experience, duplicate could use hygiene to allow all duplicates to keep the same module name, but with different hygiene. This means the user no longer has to manually assign names to each module duplicate.

The rule could be that if duplicate is applied to a module directly, hygienic renaming will kick in, however, if the module is already renamed by a substitution identifier, the hygienic renaming won't happen. This should therefore be a non-breaking change.

@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 May 28, 2020
@Emoun
Copy link
Owner Author

Emoun commented May 29, 2020

If we are doing to enable easy module duplicate, maybe also include a use super::* in the module?

@Emoun
Copy link
Owner Author

Emoun commented May 29, 2020

If we are doing to enable easy module duplicate, maybe also include a use super::* in the module?

No, as the user should be allowed to decide for themselves whether the outer scopes imports should be available for each module. This will therefore force a specific usage pattern on users.

@Emoun
Copy link
Owner Author

Emoun commented Jun 1, 2020

Using hygiene to reuse the module name may not be appropriate everywhere. F.eks. if tests are duplicated this way, there is no way to know which module failed, as they would all have the same name (to the user.)
It might therefore be useful to create some way for the user to easily change the name. E.g. maybe the first substitution identifier's substitution could be appended to the module name automatically. F.eks:

#[duplicate( 
  directedness; 
  [Directed]; 
  [Undirected] )
]
mod module {
....
}

Could expand to:

mod module_directed {
....
}
mod module_undirected {
....
}

Here notice that the directedness identifier is used inside the module. The rule could be that if the first identifier's substitutions are pure identifiers, then they are appended to the module's name in lower case.

Emoun added a commit that referenced this issue Jul 9, 2020
When enabled, if duplicate is put on a module, but that module's
name is not substituted, will automatically substitute the module's
name by using a suitable substitution identifier. See #7.
Emoun added a commit that referenced this issue Jul 9, 2020
When enabled, if duplicate is put on a module, but that module's
name is not substituted, will automatically substitute the module's
name by using a suitable substitution identifier. See #7.
@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 Jul 13, 2020
@Emoun
Copy link
Owner Author

Emoun commented Jul 13, 2020

Implemented and released in v0.2.6.

@Emoun Emoun closed this as completed Jul 13, 2020
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