Introduce #let directive for #if, and #iflet to emit error on undefined variable


  1. A directive #let = <true | false> for use in the #if <expression_using_name> #else #endif.

  2. A directive #iflet <expression_using_name> #else #endif that emits an error on an undefined .

The scope of the #let directive could be file-scoped or global. And, if defined as file-scoped then must allow for import source files containing the necessary #let directives.

The #iflet is proposed because the #if currently handles undefined as false (SWIFT_ACTIVE_COMPILATION_CONDITIONS). Having a #iflet can innately validate the build environment for correctness and guard against false-falses.


Swift 4 is not friendly to one of our methodology of code instrumentation. Swift seems to lack necessary support for #if usage modes. Currently, we can modify the Xcode build environment variables to force in -D for the #if direction using SWIFT_ACTIVE_COMPILATION_CONDITIONS in the build. However, the means is unacceptable due it cumbersome nature and risks obfuscating build issues. Implementing it proposes an explosion of schemas and targets. Instrumenting code with run-time conditions is also unacceptable and it induces bogus compiler warning, code instrumentation cannot be done without #if.

Our development methodologies involves using #if (or #ifdef in Obj-C, C++ languages) to instrument code for testing and for developing new design approaches. We need a means to flip on and off code configurations locally(per person or scheme) for the different builds, different tests, and especially for verifying new architectural changes and identifying in the code the changes involved. #if allows for injecting code snippets for testing modes of corner case conditions and debug unobservable by other means. It is best if the configurations flags are placed in at least one or more global files or in the source file of the code it affects. Our methodology for code instrumentation using the Xcode SWIFT_ACTIVE_COMPILATION_CONDITIONS build variable is not reasonable.

1 seems like the beginnings of a macro system. No thanks.

What's the benefit of 2? Also, if you're doing a lot of configuration this way, using build configurations can help, or xcconfig files can be used to encapsulate sets of flags. Or you could adjust to the fact that Swift is not C and find a different way to accomplish what you need. A multitude of preprecessor flags has never been a good idea.

:) xcconfig was the missing link! no need for new macros/directives. Thx.

Terms of Service

Privacy Policy

Cookie Policy