Assuming my current proposal about using “can import” for build configuration tests is accepted, I’d like to tackle the outstanding question of
#if debug next. This is slightly problematic because as I learned, “debug” can mean many things to different people.
For example, David Owens II writes,
I have a set of test automation that I want to ensure works. However, running this automation with a blocking assert is not what I want. Instead, I’ve created a mechanism for asserts, configurable at runtime, for the way in which those asserts are handled. During automation, I want those asserts to simply log, but code execution is not halted. During my normal dev cycle though, I want those asserts to be raised immediately so the developer sees the error and can chose to investigate or ignore the assert.
I suspect that despite this, that there is a value to supporting a general
#if debug configuration test that doesn’t require you to explicitly set command line flags with
-D <#flag#> and then test for the named flag. I’m hoping that a general utility that’s true for unoptimized builds where asserts can fire is useful enough for a sufficiently large group When I first brought up this topic, I put it this way:
Figuring out what debug *means* is an important first step. To “my people”, it’s the Xcode Build Configuration > Debug scheme setting. For language purposes, the only definition I can come up with at the moment is that debug is what happens when asserts can fire and are not disabled by compile-time optimizations.
Is that a sufficiently convenient definition for a wide enough variety of use cases that it’s worth proposing and putting the effort in to make sure this is included into the language? I need a community consensus before I commit the evolution list to another protracted discussion let alone a formal review. Your feedback will certainly help.