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. This works in some cases, but last time I checked was very buggy overall. For instance, IIRC, if it was the struct that was templated, none of its member functions had their attributes inferred like they were supposed to (I'd have to go digging through bugzilla to see what the exact set of currenly reported inferrence bugs is though). So, I think that the problem is essentially solved for @safe, pure, and nothrow as long as the implementation issues get solved. Now, as for const, I don't think that the problem has been solved yet. We really need some sort of inferrence there, which is why a number of months ago I created this enhancement request for inferring inout: http://d.puremagic.com/issues/show_bug.cgi?id=8407 AFAIK though, no one's even looked at it, so I don't think that it's had any effect as of yet. One of the compiler devs will need to take it up for it to make it in. - Jonathan M Davis
