[webkit-dev] Style proposal for branch style for macros

[Filip Pizlo]

> On Apr 20, 2014, at 12:56 PM, Mark Rowe <mrowe at apple.com> wrote:
> 
> 
>> On Apr 19, 2014, at 13:09, Filip Pizlo <fpizlo at apple.com> wrote:
>> 
>> Hey everyone,
>> 
>> When guarding code with macros that are always defined, such as ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
>> 
>> 	if (!ASSERT_DISABLED) {
>> 	    // do things
>> 	}
>> 
>> and:
>> 
>> #if !ASSERT_DISABLED
>> 	// do things
>> #endif
>> 
>> I'd like to propose that anytime the normal if would be semantically equivalent to the preprocessor #if, the normal if should be used.
>> 
>> We don't lose any compiler optimization, since even at -O0, the compiler will constant fold the normal if.  We do gain a lot of clarity, since the control flow of normal if statements is subject to proper indentation.
>> 
>> The "semantically equivalent" requirement still allows for #if to be used for thinngs like:
>> 
>> - Guarding the placement of fields in a class.
>> - Guarding the definitions of other macros (in the case of ASSERT_DISABLED, we define ASSERT in different ways guarded by #if's)
>> - Guarding the definition/declaration/inclusion of entire functions, classes, and other top-level constructs.
>> 
>> Thoughts?
> 
> It’d be one thing if we could adopt this approach everywhere, but as you note there are numerous situations in which it won’t compile. What’s worse is that there are situations in which it’ll silently give unintended behavior.

Can you give an example of this?

> It’s not clear to me what benefit you see this proposal bringing, and why it’d be worth the complexity that it adds. Given the lack of a compelling argument in favor of this change I’m firmly against it.

I would be firmly against changing any of the existing "if (!ASSERT_DISABLED)" into #if's as this would make already-gnarly JIT code even harder to follow. 

> 
> - Mark
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140420/f5d00f24/attachment.html>