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

Substitution in strings #55

Open
3 tasks
Emoun opened this issue Apr 12, 2023 · 0 comments
Open
3 tasks

Substitution in strings #55

Emoun opened this issue Apr 12, 2023 · 0 comments
Labels
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

Comments

@Emoun
Copy link
Owner

Emoun commented Apr 12, 2023

Short Description:

Enable substitution within string literals.

Motivation:

Substitution within the contents of string literals fits well with the overall functionality of duplicate.
E.g. it could be used to change the wording on some strings depending on the duplicate.

Additionally, it enables the substitution of documentation comments. Currently, to do so can only be done using the doc attribute and substituting the whole string. Not being able to substitute in docs means our examples of generating different versions of functions for e.g. mutability or async don't work well if you need the documentation to be changed too. See #54. Enabling substitution within strings should (hopefully, needs more investigation) enable substitution within /// comments directly.

Lastly, it's not immediately intuitive that substitution wouldn't work within string literals, making it a pain point for users.

Design

During substition, if a string literal is encountered, run the substitutions within it too.
To parse the contents of strings, the litrs crate can be used. See also this stackoverflow answer.

Misc:

Open questions:

  • Parsing the contents of string is not straight-forward as its would be given as &str and not TokenStream (if using littrs), meaning the normal method of identifying substitution identifiers wouldn't work. This is especially difficult with parametric substitution.
  • Should this be behind a feature flag or treated as a first-class feature?
  • Could this lead to confusion, where users wouldn't have expected substitution within strings?
@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 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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
Projects
None yet
Development

No branches or pull requests

1 participant