On 12-03-2012 18:38, Jonathan M Davis wrote:
On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote:
On 12-03-2012 14:16, deadalnix wrote:
Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
On 12-03-2012 10:40, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and template functions -
why? - because the function's implementation is guaranteed to be visible
to the compiler. For other functions, not so, and so the attributes must
be part of the function signature.
Isn't auto-inference for templates a Bad Thing (TM) since it may give
API guarantees that you can end up silently breaking?
As long as you can explicitly specify that too, and that you get a
compile time error when you fail to provide what is explicitly stated,
this isn't a problem.
But people might be relying on your API that just so happens to be pure,
but then suddenly isn't!
True, but without out, pure, @safe, and nothrow are essentially useless with
templates, because far too many templates depend on their arguments for
whether they can be pure, @safe, and/or nothrow or not. It's attribute
inference for templates that made it possible to use something stuff like
std.range and std.algorithm in pure functions. Without that, it couldn't be
done (at least not without some nasty casting). Attribute inference is
necessary for templates.
Now, that _does_ introduce the possibility of a template being to be pure and
then not being able to be pure thanks to a change that's made to it or
something that it uses, and that makes impossible for any code using it to be
pure. CTFE has the same problem. It's fairly easy to have a function which is
CTFEable cease to be CTFEable thanks to a change to it, and no one notices.
We've had issues with this in the past.
That could be solved with a @ctfe attribute or something, no? Like, if
the function has @ctfe, go through all possible CTFE paths (excluding
!__ctfe paths of course) and make sure they are CTFEable.
In both cases, I believe that the best solution that we have is to unit test
stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the
arguments support it, and then those tests can guarantee that it stays that
way in spite of any code changes, since they'll fail if the changes break
that.
- Jonathan M Davis
--
- Alex
