On Tuesday, 5 March 2024 at 03:39:41 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> 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 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.


Very clear but wordy...

s/checkPurity/canCallAsPure/    ?

On Monday, 4 March 2024 at 10:31:01 UTC, 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

Yes, buffer reuse almost always beats allocation whatever the mechanism.

On 05/03/2024 11:31 PM, ShadoLight wrote:
>     s/checkPurity/isFunctionCallableWrtPurity/
> 
>     A much longer name, but now the purpose is very clear what it does.
> 
>     True for success, false for failure.
> 
> Very clear but wordy...
> 
> s/checkPurity/canCallAsPure/ ?

Close enough that I wouldn't mention it in a PR, to any code base that I'm involved with.

All that matters is it is asking a question, not stating that it is performing an action like validation.

On 3/4/2024 7:39 PM, Richard (Rikki) Andrew Cattermole wrote:
>> 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

check* functions do more than just return status - they print error messages, too. and is* function should only answer the question.

On Monday, 4 March 2024 at 09:53:17 UTC, Walter Bright wrote:
> It means I don't have to use ! in:
>
>     if (foo())
>     {
>         error();
>         return;
>     }

Can you add a comment that says "the use of a true bool return here as an error is favored as checking `if (!foo())` results in a significant measurable performance decrease" so that when we're all dead and buried future generations will know why the backwards logic was necessary

It's not about performance, it's about competing notions of clarity.

On Saturday, 9 March 2024 at 00:09:38 UTC, Walter Bright wrote:
> It's not about performance, it's about competing notions of clarity.

Sounds like you want the guard statement...

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements/#Guard-Statement

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/thebasics/#Force-Unwrapping

On 09/03/2024 9:19 PM, Daniel N wrote:
> On Saturday, 9 March 2024 at 00:09:38 UTC, Walter Bright wrote:
>> It's not about performance, it's about competing notions of clarity.
> 
> Sounds like you want the guard statement...
> 
> https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements/#Guard-Statement
> 
> https://docs.swift.org/swift-book/documentation/the-swift-programming-language/thebasics/#Force-Unwrapping

So basically an if statement but without the true block.

I don't see why the parser couldn't support that!

Its probably even a removal of an if statement ;)

On Saturday, 9 March 2024 at 00:09:38 UTC, Walter Bright wrote:
> It's not about performance, it's about competing notions of clarity.

If you see the sentence "If file read", it reads like "if the file has been read".

That's the clarity you want.

The fact that you felt the need for a comment "//failed" on the next line belies the fact that on some level you understand that the preceding if statement is not obvious at first sight.

The simple and straight forward solution is

if (File.read(name, buf) == false)
            return null;