purity question

[Brad Roberts via Digitalmars-d-learn]

On 5/28/2017 6:36 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Sunday, May 28, 2017 17:53:25 Brad Roberts via Digitalmars-d-learn 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.
> Well, the big thing is that there are a number of functions in Phobos that
> need to have someone go over them and fix them so that they are inferred to
> be pure when they should be. Some work has been done in that area, and the
> situation is certainly better than it once was, but not enough work has been
> done to make it so that we can at all reasonably that everything in Phobos
> that should be pure is and what isn't shouldn't be.
>
>> 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. So, arguably, having anything more
> user-friendly than a cast is pretty dangerous. Having folks slap something
> like @assume_pure on things (if there were such an attribute) could be
> pretty risky. We already have enough trouble with @trusted on that front.
> Ultimately, we want to be in a position where needing to get around pure is
> very rare, and in most cases, I'd just tell folks to give up on pure on that
> piece of code rather than trying to hack it into working.
>
> - Jonathan M Davis

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.

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.