Purity, @safety, etc., in generic code

[Jonathan M Davis]

On Sunday, February 17, 2013 22:13:10 H. S. Teoh wrote:
> On Sun, Feb 17, 2013 at 09:23:44PM -0800, Jonathan M Davis wrote:
> > On Sunday, February 17, 2013 20:44:29 H. S. Teoh wrote:
> > > The thing is, AFAIK, there's no way to express "this function is
> > > pure if ElementType's opEquals is pure", ditto for const, @safe,
> > > etc.. It's all or nothing: either you force all element types to
> > > implement every qualifier, or you get none at all, even if *most*
> > > instantiations actually can get them all. Furthermore, there's
> > > currently no sane way to vary qualifiers at compile-time (so that
> > > one could, say, use static if to enable/disable qualifiers depending
> > > on what is supported).
> > 
> > @safe, pure, and nothrow are supposed to be inferred for templated
> > functions.  _That_ is how the @safe, pure, nothrow problem was
> > supposedly solved.
> 
> Oh? So you're saying that templated functions shouldn't need any
> attributes, because they will be inferred?

In general, yes. There are some cases where it may make sense to mark a 
templated function with attributes anyway, but in general, you can't, because 
the attributes may not work with some template arguments (using @trusted on 
templated functions is particularly evil). So, for the most part, @safe, pure, 
and nothrow should be unnecessary on templated functions, but the inferrence 
isn't good enough yet in a lot of cases, making it quite iffy at present.

Attribute inferrence was added precisely because without it, there was no way 
to use @safe, pure, or nothrow with std.algorithm and its ilk, not without 
requiring that all template arguments work with them, which is far too 
restrictive.

- Jonathan M Davis