2013/2/18 Jonathan M Davis <[email protected]> > 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
