| |
| Posted by Manu | PermalinkReply |
|
Manu
| On Sat, 24 Aug 2024, 03:39 Manu, <turkeyman@gmail.com> wrote:
> On Fri, 23 Aug 2024, 19:02 Iain Buclaw via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
>
>> On Friday, 23 August 2024 at 02:23:37 UTC, Nicholas Wilson wrote:
>> >
>> > GDC probably has something similar too.
>>
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect
>>
>>
>> Regarding DMD, I recall it being said that its code generator always treats the true branch as the "likely" code path taken. So if you have `if (cond) cold; else hot;`, invert the condition for the benefit of DMD.
>>
>
> Yes, I understand, and this is part of my point here; that leads to really ugly code and deep nested scopes. That's what I've been doing, and I don't want my program to look like that. It's just bad software.
>
> For instance, an extraordinarily common function pattern is to receive
> some inputs, validate a few things, and then do the thing at the end with
> valid inputs.
> Validations are usually a series of exclusionary checks framed as
> `if(fails_validity_check) return;`
> That flow keeps code in a nice linear flow, it doesn't introduce any
> scopes at all... but it's the opposite of what the assume(true) prediction
> rule wants. This is what lead me to this; almost every if statement I write
> is predicted wrong... and I definitely don't want to solve that by writing
> functions with 10 level deep nested scopes.
>
Sorry, I meant *expect(true)*, not assume! ;)
>
|