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

Jump to bottom

[SR-8818] Allow values for compilation flags (-DPARAMETER='“a string”') #51326

Open
johnno1962 opened this issue Sep 23, 2018 · 4 comments
Open

[SR-8818] Allow values for compilation flags (-DPARAMETER='“a string”') #51326

johnno1962 opened this issue Sep 23, 2018 · 4 comments
Labels
compiler The Swift compiler in itself feature A feature request or implementation swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal

Comments

@johnno1962
Copy link
Contributor

Previous ID SR-8818
Radar None
Original Reporter @johnno1962
Type New Feature
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels New Feature, LanguageFeatureRequest
Assignee None
Priority Medium

md5: f8119f3bd3d2e0c08396d510a15e15b0

Issue Description:

For things like build dates and times and parameters that could come from build configurations it could be useful to be able to provide values for compilation flags as you can with the C compiler for example:

swift -DBUILD_NUMBER=1234 -DTOLLERANCE=0.9 -DBUILD_DATE=‘"Sun 23 Sep 2018 11:47:20”’ file.swift

I have in mind a simple implementation that these parameters would have module scope and be just substituted when the parameter name was referred to as if the user had typed them. A straight forward implementation intercepting identifiers in the Lexer is available here johnno1962#1
@belkadan
Copy link
Contributor

This would need to go through the Swift Evolution Process.

@belkadan
Copy link
Contributor

Also, it's not just about "allowing values". There are several possible things you could do with these:

  • test for their existence in #if

  • test for them having a certain value in #if

  • use them as values (implicit internal variables, maybe?)

@johnno1962
Copy link
Contributor Author

Evolution is probably inevitable on this one - there are so many degrees of freedom.

#If works as before. The implementation will see a true value for any defined value other than “false". It’s inevitable there will be attempted scope creep for expressions on #if as is mentioned in the forums but the current implementation of #if is very limited.

If you want expressions you can always use a normal “if” though you’ll end up with a warning along the lines of “such-in-such is always true/false”.

The plan is these flags come through as an alias to a literal as if typed in the source not internal variables. This is so their type can be determined by their context and keeps the implementation straightforward.

@johnno1962
Copy link
Contributor Author

Evolution proposal PR’d apple/swift-evolution#917 along with implementation of sorts #19585

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal and removed new feature labels Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler The Swift compiler in itself feature A feature request or implementation swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @johnno1962 @AnthonyLatsis