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
