purity question

[Brad Roberts via Digitalmars-d-learn]

On 5/28/2017 6:27 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Monday, May 29, 2017 01:01:46 Stefan Koch via Digitalmars-d-learn wrote:
>> On Monday, 29 May 2017 at 00:53:25 UTC, Brad Roberts wrote:
>>> On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn
>>>
>>> wrote:
>>>> On Sunday, May 28, 2017 16:49:16 Brad Roberts via
>>>>
>>>> Digitalmars-d-learn wrote:
>>>>> Is there a mechanism for declaring something pure when it's
>>>>> built from
>>>>> parts which individually aren't?
>>>>>
>>>>> string foo(string s)
>>>>> {
>>>>>
>>>>>        // do something arbitrarily complex with s that doesn't
>>>>>
>>>>> touch
>>>>> globals or change global state except possibly state of the
>>>>> heap or gc
>>>>>
>>>>>        return s;
>>>>>
>>>>> }
>>>> <snip lecture> you can cast </snip lecture>
>>> Ok, so there essentially isn't.  I'm well aware of the risks of
>>> lying to the compiler, but it's also not sufficiently smart to
>>> unravel complex code.  Combined with there being interesting
>>> parts of the standard 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.
>> There is
>>
>> void[] myPureMalloc(uint size) pure @trusted nothrow @nogc
>> {
>>      alias pure_malloc_t = pure nothrow void* function(size_t size);
>>      return (cast(pure_malloc_t)malloc)(size)[0 .. size];
>> }
> There was a whole discussion or 3 is PRs about making malloc pure, and IIRC,
> it was done and then decided that it wasn't safe to do some for one reason
> or another (IIRC, it had to do with what would happen when calls were
> elided, because the caller was strongly pure, but I'm not sure). So, I'd be
> _very_ careful about deciding that it was safe to call malloc in pure code.
> I expect that it's just fine in some contexts, but it's easy enough to screw
> up and mark something as pure when it really shouldn't be because of some
> detail you missed that you should be _really_ careful about decided to cast
> to pure.
>
> - Jonathan M Davis

That's one reason I explicitly referenced malloc/free pairs.  It's a lot 
easier to be sure that those together aren't violating purity.