Purity, @safety, etc., in generic code

[Jonathan M Davis]

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