www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - "if not" condition check (for data validation)

reply Denis <noreply noserver.lan> writes:
Is there a cleaner way to implement an "if not" condition check?

WHY NOT JUST USE "IF"?

For data validation, code is cleaner and more intelligible if the 
condition being checked is written in an affirmative sense; that 
is, in the same way that `assert` is written. This is especially 
true when `and` and `or` logic is involved. `if` is not a good 
substitute, because it works in the opposite sense, often 
requiring lots of `not`s. As a trivial example:

   assert( configfile.isFile && configfile.extension == ".conf" )
     -vs-
   if ( !configfile.isFile || configfile.extension != ".conf" ) 
<handle it>

An `if` statement can be written in the affirmative sense, by 
using an empty `then` statement + an `else` statement:

   if ( configfile.isFile && configfile.extension == ".conf", 
message ) { }
   else <handle it>

But then the logic intuitively feels wrong for an `if`, because 
the handler is always in the `else`. When there are only a few 
such checks, it might not matter. But when there are a lot of 
checks, the code gets ugly (lots of `else`s) and the clutter adds 
up.

ORIGINAL SOLUTION

The following solution works and the code is very readable. 
However, it has a couple of notable deficiencies.

   void unless(T)(T condition, lazy void func ) {
       if ( !condition ) func(); }
    :
   unless( configfile.isFile && configfile.extension == ".conf", 
handleIt( _ _ ));

The most obvious shortcomings are:
   1. It only works with a handler function. So `continue` and the 
like can't be used, for example.
   2. It is inefficient, adding an extra function call to every 
condition check. Inside a loop, this is cumulative.

A BETTER SOLUTION ???

I haven't been able to come up with another option that is more 
efficient yet doesn't sacrifice readability. I would welcome 
suggestions.

Thanks in advance.
Denis
Jun 17 2020
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 17 June 2020 at 23:46:54 UTC, Denis wrote:

 `if` is not a good substitute, because it works in the opposite 
 sense, often requiring lots of `not`s. As a trivial example:

   assert( configfile.isFile && configfile.extension == ".conf" )
     -vs-
   if ( !configfile.isFile || configfile.extension != ".conf" )



 A BETTER SOLUTION ???

 I haven't been able to come up with another option that is more 
 efficient yet doesn't sacrifice readability. I would welcome 
 suggestions.

 Thanks in advance.
 Denis


if( ! (configfile.isFile && configfile.extension == ".conf") )

?
Jun 17 2020
parent Denis <noreply noserver.lan> writes:
On Thursday, 18 June 2020 at 00:43:40 UTC, Stanislav Blinov wrote:

 if( ! (configfile.isFile && configfile.extension == ".conf") )

 ?


That does indeed clean up the compound logic. One is still left 
with:

   if( !(
   if( !
   if( !(
   if( !
    :

I was hoping to get away from all the `not`s too.
Jun 17 2020
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/17/20 4:46 PM, Denis wrote:> Is there a cleaner way to implement an 
"if not" condition check?


    if ( configfile.isFile && configfile.extension == ".conf", message 


) { }

    else <handle it>


   if (isConfigFile(name)) {
     // ...

   } else {
     // ...
   }

The following is suitable in many cases:

   enforce(isConfigFile(name), format!"%s is not a config file"(name));
   // ...

I shortened that in many occasions:

   enforceConfigFile(name);
   // ...

Of course, depending on the situation it is assert() or assertConfigFile().

Ali
Jun 17 2020
parent reply Denis <noreply noserver.lan> writes:
Let me clarify the requirements and rephrase the question --

REQUIREMENTS

`assert`, `enforce` and the `unless` function I wrote (above) all 
allow the condition to be expressed in an affirmative sense, and 
they also achieve the goal of readability. These are the initial 
requirements.

`unless` improves on `assert` and `enforce` by allowing a custom 
action to be specified. This might be to write an error message 
and exit (like `assert` and `enforce`). But it could also be to 
write a warning message (to console or a log file) but not exit. 
So the next requirement is to be able to specify a custom action.

Unfortunately a function, like the one I wrote, doesn't work 
because it doesn't allow actions that would skip or repeat some 
code (`continue`, `goto`, etc) to be specified as the second 
argument. It also doesn't allow code to be skipped or repeated 
after executing the function in the second argument. (That is, 
after writing a warning message or log notice, continue 
processing at some point.) A conditional operator like `if` is 
needed, not a function.

THE ESSENTIAL QUESTION

Is there a way to write an `unless` operator that would allow the 
condition to be expressed in an affirmative sense? It would be 
used like `if`, i.e. something like:

    unless ( <condition> ) {
      <handle it>;		// Or even: <ignore it>
      continue; }

Templates offer a clean syntax, but I can't come up with a way to 
use them for a conditional operator. Mixins are flexibile, but I 
suspect the result would not be very readabile (that is, less 
readable even than "if ( ! (..." ). I was hoping that some 
feature, or combination of features, in D might allow this to be 
achieved.
Jun 18 2020
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Thursday, 18 June 2020 at 12:13:21 UTC, Denis wrote:


 THE ESSENTIAL QUESTION

 Is there a way to write an `unless` operator that would allow 
 the condition to be expressed in an affirmative sense? It would 
 be used like `if`, i.e. something like:

    unless ( <condition> ) {
      <handle it>;		// Or even: <ignore it>
      continue; }

 Templates offer a clean syntax, but I can't come up with a way 
 to use them for a conditional operator. Mixins are flexibile, 
 but I suspect the result would not be very readabile (that is, 
 less readable even than "if ( ! (..." ). I was hoping that some 
 feature, or combination of features, in D might allow this to 
 be achieved.


No, there isn't a way to write an operator. And yes, with 
templates you could do something like

auto not(alias cond)() { return !cond(); }

if (not!(() => abra && cadabra)) ...

but that is indeed even less readable.
Jun 18 2020
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 18 June 2020 at 12:50:35 UTC, Stanislav Blinov wrote:

 auto not(alias cond)() { return !cond(); }

 if (not!(() => abra && cadabra)) ...

 but that is indeed even less readable.


No reason to use templates here

```
pragma(inline, true) auto not(bool cond) { return !cond(); }

if (not!(abra && cadabra)) ...
//same as above
if (abra.not || cadabra.not) ...
```
Jun 18 2020
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:

 if (not!(abra && cadabra)) ...


if (not(abra && cadabra)) ...
Jun 18 2020
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 18 June 2020 at 13:58:33 UTC, Dukc wrote:

 On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:

 if (not!(abra && cadabra)) ...


 if (not(abra && cadabra)) ...


Which is a quite a complicated way to write

if (!(abra && cadabra)) ...
Jun 18 2020
parent reply Denis <noreply noserver.lan> writes:
On Thursday, 18 June 2020 at 12:50:35 UTC, Stanislav Blinov wrote:

 No, there isn't a way to write an operator.


OK, first choice eliminated.

On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:

 No reason to use templates here

 pragma(inline, true) auto not(bool cond) { return !cond(); }


I like it. The inline pragma eliminates the extra overhead of the 
function call, which was another objective. (And it introduces me 
to D's pragmas too.)

Personally, I find this:

   if ( not( abra && cadabra )) ...

to be more clear than:

   if ( !( abra && cadabra )) ...

I guess it depends on what one is used to. I do recognize that 
this would be non-standard for D, but I'm still going to use it 
because I find it more readabile.

I should add that this one made me laugh though, giving 
flashbacks to that horrible "not speak" of the early 90s:

   if ( configfile.isFile.not ) ...

LOL

I've learned multiple things from this posting. Thank you all for 
sharing your suggestions.

Denis
Jun 18 2020
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Thursday, 18 June 2020 at 17:39:44 UTC, Denis wrote:


 I should add that this one made me laugh though, giving 
 flashbacks to that horrible "not speak" of the early 90s:

   if ( configfile.isFile.not ) ...

 LOL


Approve Yoda does.
Jun 19 2020
prev sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:


 No reason to use templates here


Pff. Me no think straight. -.-
Jun 18 2020
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/18/20 5:13 AM, Denis wrote:


 Templates offer a clean syntax


Here is an earlier experiment of nested templates, which may be useful 
in this case. This is unrelated to your problem but the syntax can be 
pretty readable with templates:

// If there are template arguments, then the result is the first of
// them. If there is no argument, then the result is the argument
// of 'otherwise'.
template FirstOf(T...) {
   template otherwise(alias D) {
     static if (T.length != 0) {
       enum otherwise = T[0];

     } else {
       enum otherwise = D;
     }
   }
}

unittest {
   static assert (FirstOf!(1.5, "hello").otherwise!100 == 1.5);
   static assert (FirstOf!().otherwise!42 == 42);
}

auto foo(Args...)() {
   auto temp = FirstOf!Args.otherwise!1.5;
   // ...
   return temp + 0.5;
}

unittest {
   assert(foo!(10, int[])() == 10.5);
   assert(foo() == 2.0);
}

void main() {
}

I think you should be able to pass callables as 'alias' template 
arguments but I couldn't put much thought into it.

Ali
Jun 18 2020
parent Denis <noreply noserver.lan> writes:
On Thursday, 18 June 2020 at 17:57:49 UTC, Ali Çehreli wrote:

 Here is an earlier experiment of nested templates, which may be 
 useful in this case.


     :

 I think you should be able to pass callables as 'alias' 
 template arguments


Sounds good. This gives me an opportunity to learn how nested 
templates can be used. `alias` in this context is also new, so 
I'll dig into that too.

Thanks!
Jun 18 2020