Purity, @safety, etc., in generic code

[H. S. Teoh]

On Sun, Feb 17, 2013 at 09:23:44PM -0800, Jonathan M Davis wrote:
> 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.

Oh? So you're saying that templated functions shouldn't need any
attributes, because they will be inferred?


> 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.

It would be nice if we could work on this. One of D's major selling
points right now is its metaprogramming features; but that is a bit
tarnished by the poor attribute inference.


> 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.
[...]

It would be *very* nice if const inference were implemented. It would
greatly increase the practicality of D's const. Right now, I'm forced to
forego const-correctness in many places because of these kinds of
issues.


T

-- 
Let's call it an accidental feature. -- Larry Wall