Purity, @safety, etc., in generic code

[kenji hara]

2013/2/18 Jonathan M Davis <jmdavisProg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130218/3a14b1ea/attachment.html>