On Monday, 4 March 2024 at 20:38:05 UTC, Paul Backus wrote:
> FWIW when I was new to the DMD codebase, I found it very confusing to read this kind of code. And it doesn't help that DMD is internally inconsistent about its use of bool.
>
> For example, you have this:
>
>     // true means success
>     if (f.isPure())
>         // it's pure
>     else
>         // it's impure
>
> ...but also this:
>
>     // true means failure
>     if (f.checkPurity(loc, sc))

"Safe 'check' for chess" [1]

>         // it's impure
>     else
>         // it's pure
>
> ...but also this:
>
>     // true means success
>     if (checkSymbolAccess(sc, sym))
>         // it's accessible
>     else
>         // it's not accessible
>
> ...but also this:
>
>     // true means failure
>     if (checkAccess(loc, sc, e, sym))
>         // it's not accessible
>     else
>         // it's accessible

And yesterday I found a post where an "is" function does not return
a bool [2]:

https://github.com/dlang/dmd/pull/16280/files
package CppOperator isCppOperator(const scope Identifier id)


[1] https://jhall.io/archive/2021/09/29/save-check-for-chess/
[2] https://forum.dlang.org/post/us0248$1ttt$1@digitalmars.com

On 3/4/2024 3:40 AM, Dom DiSc wrote:
> That's a very weak argument.
> Normally if one calls a function, the if-part is where the result is worked with (the main path) and the else part is for error-handling. This is especially true for ReadFile().
> That in this specific case only an error handling part exists is the exception, not the rule.

Don't think I haven't struggled with this question.

Consider also that the convention for system calls is 0 is success and anything else is an error.

On 3/4/2024 12:38 PM, Paul Backus wrote:
> For example, you have this:
> 
>      // true means success
>      if (f.isPure())
>          // it's pure
>      else
>          // it's impure
> 
> ...but also this:
> 
>      // true means failure
>      if (f.checkPurity(loc, sc))
>          // it's impure
>      else
>          // it's pure

I know there are inconsistencies in the DMD code base. It shows the effects of many people working on it over decades.

However, "isPure" asks a question. "checkPurity" does not, and so it isn't implicit how the logic should go.

On 3/4/2024 2:57 PM, kdevel wrote:
> And yesterday I found a post where an "is" function does not return
> a bool [2]:
> 
> https://github.com/dlang/dmd/pull/16280/files
> package CppOperator isCppOperator(const scope Identifier id)

Correct, but it isn't that bad. The "is", when treated as a bool, gives a result that correctly answers the question.

On 3/4/2024 2:31 AM, Hipreme wrote:
> Good refactor, this also may open a big door to easier optimizations as you get better isolation. Beyond that, I think it may be first step towards having parallelizable compiler

That observation hasn't escaped me :-)

I've made many recent refactorings that eliminate global state.

On 05/03/2024 4:29 PM, Walter Bright wrote:
> On 3/4/2024 12:38 PM, Paul Backus wrote:
>> For example, you have this:
>>
>>      // true means success
>>      if (f.isPure())
>>          // it's pure
>>      else
>>          // it's impure
>>
>> ...but also this:
>>
>>      // true means failure
>>      if (f.checkPurity(loc, sc))
>>          // it's impure
>>      else
>>          // it's pure
> 
> I know there are inconsistencies in the DMD code base. It shows the effects of many people working on it over decades.
> 
> However, "isPure" asks a question. "checkPurity" does not, and so it isn't implicit how the logic should go.

s/checkPurity/isFunctionCallableWrtPurity/

A much longer name, but now the purpose is very clear what it does.

True for success, false for failure.

Based upon my understanding of its body it looks like this is a valid name/behavior.

https://github.com/dlang/dmd/blob/95ba36a3fdd46850666aaebf2db31dd7c5dc9012/compiler/src/dmd/expressionsem.d#L1860

On Monday, 4 March 2024 at 09:53:17 UTC, Walter Bright wrote:
> On 3/4/2024 12:06 AM, Dom DiSc wrote:
>> But why does it now return true on failure and false on success?
>> Isn't this exacly the bad re-definition of boolean you advised us not to use?
>
>
> It means I don't have to use ! in:
>
>     if (foo())
>     {
>         error();
>         return;
>     }

We really need to come up with one, standard way of reporting failure/success.

On Tuesday, 5 March 2024 at 03:31:28 UTC, Walter Bright wrote:
> On 3/4/2024 2:57 PM, kdevel wrote:
>> And yesterday I found a post where an "is" function does not return
>> a bool [2]:
>> 
>> https://github.com/dlang/dmd/pull/16280/files
>> package CppOperator isCppOperator(const scope Identifier id)
>
> Correct, but it isn't that bad. The "is", when treated as a bool, gives a result that correctly answers the question.

Sure, but on the one hand that function is nowhere used as a predicate. These are the only two invocations I found (in dmd 2.105.3):

cppmangle.d:

   1216         // test for special symbols
   1217         CppOperator whichOp = isCppOperator(ti.name);
   1218         final switch (whichOp)

cppmanglewin.d:

   1164     auto whichOp = isCppOperator(ti.name);
   1165     final switch (whichOp)

whichOp is not used in boolean context either.

On the other hand after your rewrite of isCppOperator there are
different values which map to false:

old: enum CppOperator { Cast, Assign, Eq, Index, Call, Unary, Binary, OpAssign, Unknown }
new: enum CppOperator { Unknown, Cast, Assign, Eq, Index, Call, Unary, Binary, OpAssign }

On Tuesday, 5 March 2024 at 03:26:22 UTC, Walter Bright wrote:
> Don't think I haven't struggled with this question.
>
> Consider also that the convention for system calls is 0 is success and anything else is an error.

I know, and it is odd enough. But here it is boolean. "Anything else" is just one value: true. And "true" should never be the error value.
Use any other type, and say 1 means "error code 1" instead of "true" and then it's ok.
0 is a neutral value, false is not. This is also one major reason to not automatically convert from int to bool or vice versa. Because then false becomes 0 which changes the meaning heavily.

On Tuesday, 5 March 2024 at 09:33:35 UTC, Dom DiSc wrote:
> On Tuesday, 5 March 2024 at 03:26:22 UTC, Walter Bright wrote:
>> Don't think I haven't struggled with this question.
>>
>> Consider also that the convention for system calls is 0 is success and anything else is an error.
>
> I know, and it is odd enough. But here it is boolean. "Anything else" is just one value: true. And "true" should never be the error value.
> Use any other type, and say 1 means "error code 1" instead of "true" and then it's ok.
> 0 is a neutral value, false is not. This is also one major reason to not automatically convert from int to bool or vice versa. Because then false becomes 0 which changes the meaning heavily.

I have an idea, since you all have such boundless energy for nitpicking the most arcane of trivial minutia, could some of you all direct this clear abundance of energy to JMD's Range Redesign thread here: https://forum.dlang.org/thread/mailman.1075.1709587824.3719.digitalmars-d@puremagic.com

Or maybe any of the Discussions here? https://github.com/LightBender/PhobosV3-Design/discussions

We're gearing up to redesigns ranges as we start pulling things into Phobos V3 and we could use some of this energy over there.