2013/2/18 Jonathan M Davis <jmdavisProg@gmx.com>
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.

(This is just my personal schedule)

In 2.062, followings are merged
- #1543 Issue 5933 & 7159 & 9377 - Invoke function semantic3 correctly where it is required
- #1096 Issue 8504 - Template attribute inferrence doesn't work
- #1381 Issue 8847 - voldemort + inout confuses "is"

In my thought, they were blockers for implementing 7511.
- Issue 7511 - attribute inference does not work for methods of templated aggregates

So, I'll begin to implement experimental patch for 7511 in near future.
 
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.

I think const must not be inferred for member function, because it affects to the function overloading. For example, the const-ness for class method will be inferred from base class overridden method with current compiler, but it causes a serious problem.

http://d.puremagic.com/issues/show_bug.cgi?id=8366

Instead, you should declare two methods in generic code - one is mutable, and another is const/inout.

Kenji Hara