<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/2/18 Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Sunday, February 17, 2013 20:44:29 H. S. Teoh wrote:<br>
> The thing is, AFAIK, there's no way to express "this function is pure if<br>
> ElementType's opEquals is pure", ditto for const, @safe, etc.. It's all<br>
> or nothing: either you force all element types to implement every<br>
> qualifier, or you get none at all, even if *most* instantiations<br>
> actually can get them all. Furthermore, there's currently no sane way to<br>
> vary qualifiers at compile-time (so that one could, say, use static if<br>
> to enable/disable qualifiers depending on what is supported).<br>
<br>
</div>@safe, pure, and nothrow are supposed to be inferred for templated functions.<br>
_That_ is how the @safe, pure, nothrow problem was supposedly solved. This<br>
works in some cases, but last time I checked was very buggy overall. For<br>
instance, IIRC, if it was the struct that was templated, none of its member<br>
functions had their attributes inferred like they were supposed to (I'd have<br>
to go digging through bugzilla to see what the exact set of currenly reported<br>
inferrence bugs is though). So, I think that the problem is essentially solved<br>
for @safe, pure, and nothrow as long as the implementation issues get solved.<br></blockquote><div><div><br></div><div>(This is just my personal schedule)</div><div><br></div><div>In 2.062, followings are merged</div><div>
- #1543 Issue 5933 & 7159 & 9377 - Invoke function semantic3 correctly where it is required</div><div>- #1096 Issue 8504 - Template attribute inferrence doesn't work</div><div>- #1381 Issue 8847 - voldemort + inout confuses "is"</div>
<div><br></div><div>In my thought, they were blockers for implementing 7511.</div><div>- Issue 7511 - attribute inference does not work for methods of templated aggregates</div><div><br></div><div>So, I'll begin to implement experimental patch for 7511 in near future.</div>
</div><div> <br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Now, as for const, I don't think that the problem has been solved yet. We<br>
really need some sort of inferrence there, which is why a number of months ago<br>
I created this enhancement request for inferring inout:<br>
<br>
<a href="http://d.puremagic.com/issues/show_bug.cgi?id=8407" target="_blank">http://d.puremagic.com/issues/show_bug.cgi?id=8407</a><br>
<br>
AFAIK though, no one's even looked at it, so I don't think that it's had any<br>
effect as of yet. One of the compiler devs will need to take it up for it to<br>
make it in.</blockquote><div><br></div><div>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.</div>
<div><br></div><div><a href="http://d.puremagic.com/issues/show_bug.cgi?id=8366">http://d.puremagic.com/issues/show_bug.cgi?id=8366</a></div><div><br></div><div>Instead, you should declare two methods in generic code - one is mutable, and another is const/inout.</div>
<div><br></div><div>Kenji Hara</div></div></div></div>