Skip to content

Make NameSpecification and its element ExpressibleByStringLiteral #745

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

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

Conversation

natecook1000
Copy link
Member

This simplifies declaring alternate names by allowing just a string representation of an option or flag name. The string is parsed to split on spaces, and then validates that each name has either a one or two dash prefix and is ASCII only.

Existing style:

@Flag(name: [.customLong("hex-output"), .customShort("x")])
var hexadecimalOutput = false

New style:

@Flag(name: "--hex-output -x")
var hexadecimalOutput = false

Checklist

  • I've added at least one test that validates that my change is working, if appropriate
  • I've followed the code style of the rest of the project
  • I've read the Contribution Guidelines
  • I've updated the documentation if necessary

This simplifies declaring alternate names by allowing just
a string representation of an option or flag name. The string
is parsed to split on spaces, and then validates that each
name has either a one or two dash prefix and is ASCII only.

Existing style:

    @Flag(name: [.customLong("hex-output"), .customShort("x")])
    var hexadecimalOutput = false

New style:

    @Flag(name: "--hex-output -x")
    var hexadecimalOutput = false
@rgoldberg
Copy link
Contributor

@natecook1000 Is there any spec for the valid characters for each possible part of a command line (including first characters; e.g., I assume that subcommands shouldn't start with a -)?

Are such restrictions programmatically enforced in a centralized place?

@natecook1000
Copy link
Member Author

@rgoldberg No, we don't have any of that validation in place. There's a certain degree of self-enforcement in place, in that things will just not work properly if you do things like defining an option with a space in its name. But we should add some of that, and can be more stringent in this case, since it's a new behavior.

@rgoldberg
Copy link
Contributor

rgoldberg commented Feb 27, 2025

@natecook1000 Thanks for the info.

The problem that I see with being more stringent in this case is, e.g., that someone could have an existing flag name that contravenes the new restrictions for this feature. One would assume that flag names should work everywhere or nowhere, not for some features but not for others.

I'm very much in favor of explicit character restrictions, but I think it's best to programmatically enforce them all in one central place & to document them, then to use & rely on those restrictions throughout.

I would assume that enacting the restrictions would require a new major version of SAP, in case now-invalid characters were used with the existing major version.

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.

2 participants