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.
