Generic memory allocation in D

https://github.com/dlang/dmd/pull/16291 I had talked about this in the last DConf. Here's another example of how memory allocation can be user-controlled rather than selected by the algorithm. I've been turning to this more and more with DMD and the results are good.

On Monday, 4 March 2024 at 07:35:52 UTC, Walter Bright wrote: > https://github.com/dlang/dmd/pull/16291 > > I had talked about this in the last DConf. Here's another example of how memory allocation can be user-controlled rather than selected by the algorithm. I've been turning to this more and more with DMD and the results are good. Nice. 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?

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; }

On Monday, 4 March 2024 at 07:35:52 UTC, Walter Bright wrote: > https://github.com/dlang/dmd/pull/16291 > > I had talked about this in the last DConf. Here's another example of how memory allocation can be user-controlled rather than selected by the algorithm. I've been turning to this more and more with DMD and the results are good. 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

On Monday, 4 March 2024 at 09:53:17 UTC, Walter Bright wrote: > On 3/4/2024 12:06 AM, Dom DiSc wrote: >> 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; > } 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.

March 04

Re: Generic memory allocation in D

Posted by Dennis
in reply to Walter Bright

Permalink

Dennis

Posted in reply to Walter Bright

Permalink

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;
}

It's confusing how sometimes 0 is used for success, and other times 0 is used for failure.
For a boolean it makes more sense for true to be success, so the Windows API uses it, as you can see in the PR:

if (!CloseHandle(h))
    return Failure;

This reads as "if I could not close the handle, return failure".

There's often only 1 success state and many error states however. In that case you might want to return an int with multiple error codes, but there's only one 0. This code could also make sense:

if (auto errorCode = CloseHandle(h))
    return errorCode;

Now the error case is 'truthy'. Unfortunately, I don't think D can help differentiate between the two cases to prevent mistakes when using APIs returning success / error states.

On 04/03/2024 10:53 PM, 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; > } As others have suggested, the truthiness here kinda matters and very much goes against the grain of pretty much what everyone does. It is going to cause readers a problem (and yourself!) in the future.

On Monday, 4 March 2024 at 14:16:17 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 04/03/2024 10:53 PM, 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; >> } > > As others have suggested, the truthiness here kinda matters and very much goes against the grain of pretty much what everyone does. > > It is going to cause readers a problem (and yourself!) in the future. Had you used another type, like int, then it would follow standard practise much better that 0 is okay, but for bool... sorry despite the rest of your patch being great, I don't love unintuitive bools.

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; > } 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)) // 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

On Monday, 4 March 2024 at 20:38:05 UTC, Paul Backus wrote: > 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; >> } > > 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)) > // 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 Lol, if I were reviewing code that did this from one of my team members at work, their PR would definitely NOT be getting approved.

Forums