This was suggested in https://github.com/microsoft/AL/issues/278 and closed with the very reasonable response:

>>>
C/AL have never had short-circuit boolean evaluation. This is legacy and I agree it is uncommon today.

Unfortunately this is not just something we can change. Not only does all our own AL code rely on that, but also all the code written by partners.
>>>

I recall that Visual Basic (at least for Applications!) also has non-short-circuiting And/Or operators, but eventually it got short-circuiting replacements in the form of the AndAlso/OrElse operators. As in C, C++, C#, etc. - these will not evaluate 2nd or later conditions if the end result can be determined by an earlier one.

Having these would mean that common nest-of-doom AL code like

```al
if GuiAllowed() then
if FindSomeRecord() then
if Confirm(SomethingQst) then
DoAThing();
```

could instead be

```al
if GuiAllowed() andalso FindSomeRecord() andalso Confirm(SomethingQst) then
DoAThing();
```

or

```al
if GuiAllowed() then begin
if Confirm(SomethingQst) then
Barp();
end else
Barp();
```

could become

```al
if not GuiAllowed() orelse Confirm(SomethingQst) then
Barp();
```

(a bit of a contrived example when ConfirmManagement exists, but you get the point!)

and so on - removing a lot of theoretically unnecessary nesting, and giving AL another area of parity with modern languages.

Obviously I only suggest "andalso"/"orelse" because I base this on VB adding AndAlso/OrElse operators. I'd be happy for names that look better in all lower-case, as is the idiom for AL keywords.

Thanks for considering!