Returning int instead of bool can actually make things _less_ efficient

[Stewart Gordon]

Karen Lanrap wrote:
> Stewart Gordon wrote:
> 
>> For example, of these, which is more efficient? 
> 
> This cannot be answered in general, because at least the features of 
> the CPU and the code context play a major role.

Exactly.  That's why I said next:

>> If the compiler knows that b and c are boolean, it could optimise 
>> one form to the other, whichever is quicker on the processor for 
>> which the code is being compiled.

But when you mention "code context", do you mean that these expressions 
could be parts of larger expressions and this could affect what 
generated code is best?  Obviously optimisation would take this into 
consideration.

> In fact Walters main argument for not having bool was an adaption to 
> the _current_ behaviour of CPU producers whereas your argument seems 
> right that a more precise abstraction may gain efficiency benefits.

But D does have bool now.  And it would be silly if we didn't use it.

> To actually have this benefits I do not see any other way than to 
> implicitely follow the success of bytecode/VM implementations by 
> deferring such decisions to the time of installation.

But the D compiler generates native code.  I'm not sure how we can make 
any meaningful changes to this native code at anything other than 
compile-time.

> Such deferring may also provide benefits on a larger scale: for 
> example when a CPU outperforms its competitors for a specific task, a 
> set of implementations of algorithms may also outperform another such 
> set, especially if CPU can flag their capabilities.
<snip>

Hmm....

Stewart.