On 5/28/2017 6:46 PM, Brad Roberts via Digitalmars-d-learn wrote:
>
> Here's the bug that I'm digging into today, a clear example of an api that _should_ be pure, but based on the implementation is rather difficult for the compiler to infer.

https://issues.dlang.org/show_bug.cgi?id=17442

On Sunday, May 28, 2017 18:46:22 Brad Roberts via Digitalmars-d-learn wrote:
> Again, of course it's possible to do it wrong.  Escape hatches are like that.  And of course things are being worked on and improved, I'm one of the ones that's done a good bit of that at various points in time.  I'm really not seeking a lesson or lecture in why it's dangerous.

Sorry, if I'm coming across like I'm lecturing you. I'm not trying to. I'm trying to be clear about the situation, and because this is on D.Learn, with something like this, I don't want to show how to get around the issue without clearly warning about the risks, because even if you know exactly what you're doing when casting to get around purity problems, many others reading this list will not.

- Jonathan M Davis

Brad Roberts wrote:

> libraries that themselves aren't marked pure, there's a real need for escape hatches.  A simple example: anything that has a malloc/free pair.

they aren't pure. it is a sad misconception about purity, which D makes even more complex by allowing to mark, for example, *setters* as pure. but still, `malloc()` and `free()` aren't pure. and while various functions in std.math, for example, are marked `pure`, they aren't too.

On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote:
> pure. and while various functions in std.math, for example, are marked `pure`, they aren't too.

Out of curiosity, which functions in std.math aren't "pure" in the D sense?

Ola Fosheim Grøstad wrote:

> On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote:
>> pure. and while various functions in std.math, for example, are marked `pure`, they aren't too.
>
> Out of curiosity, which functions in std.math aren't "pure" in the D sense?

almost all of them, 'cause they depends on FPU rounding settings.

On Monday, 29 May 2017 at 11:25:06 UTC, ketmar wrote:
> almost all of them, 'cause they depends on FPU rounding settings.

Well, yeah. IIRC contemporary floating point machine language instructions allow embedding of rounding mode into the instruction.

A pity languages are lagging behind, stuck in the 1980s...

WebAssembly is locking it to the default IEEE754-2008 round-to-even. Which is reasonable as they aim for max portability, albeit a bit limiting.

On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote:
> Brad Roberts wrote:
>
>> libraries that themselves aren't marked pure, there's a real need for escape hatches.  A simple example: anything that has a malloc/free pair.
>
> they aren't pure. it is a sad misconception about purity, which D makes even more complex by allowing to mark, for example, *setters* as pure. but still, `malloc()` and `free()` aren't pure. and while various functions in std.math, for example, are marked `pure`, they aren't too.

There is pureMalloc since 2.074.0 (it was never announced):

https://github.com/dlang/druntime/pull/1746

However, without a pureFree it's rather limited in usefulness and needs to be workaround in real life:

https://github.com/dlang/druntime/pull/1718

On Monday, 29 May 2017 at 01:36:24 UTC, Jonathan M Davis wrote:
>> A simple example: anything that has a malloc/free pair.
>
> Yeah, if you do it right, you should be fine, but you have to do it right, and it's very easy to miss some detail that makes it wrong to insist to the compiler that what you're doing is pure.

If malloc were marked as pure, wouldn't that mean it must return the same pointer every time you call it with the same size?

Rene Zwanenburg wrote:

> On Monday, 29 May 2017 at 01:36:24 UTC, Jonathan M Davis wrote:
>>> A simple example: anything that has a malloc/free pair.
>>
>> Yeah, if you do it right, you should be fine, but you have to do it right, and it's very easy to miss some detail that makes it wrong to insist to the compiler that what you're doing is pure.
>
> If malloc were marked as pure, wouldn't that mean it must return the same pointer every time you call it with the same size?

of course. but D "pure" is not what other world knows as "pure". we love to mess with words.

On Tuesday, 30 May 2017 at 11:34:52 UTC, ketmar wrote:
>> If malloc were marked as pure, wouldn't that mean it must return the same pointer every time you call it with the same size?
>
> of course. but D "pure" is not what other world knows as "pure". we love to mess with words.

Well, there's the ability to modify non-const reference parameters from a pure function, but that's not applicable to malloc. Are there any other special rules?