Bug 8138 – Attribute inference fails with Voldemort type

This stripped down code from one of my programs import std.algorithm; import std.range; import std.traits; void main() { ubyte[] buffer = [1, 2, 9, 7, 6]; auto filtered = filter!"true"(buffer); auto br2 = bitReader(filtered); } final class BitReader(R) if(isInputRange!R && is(ElementType!R : const ubyte)) { this(R)(R bytes) { _bytes = bytes; } @property bool empty() const { return _bytes.empty; } R _bytes; } BitReader!R bitReader(R)(R r) if(isInputRange!R && is(ElementType!R : const ubyte)) { return new BitReader!R(r); } results in this compilation error: q.d(24): Error: function std.algorithm.filter!("true").filter!(ubyte[]).filter.Result.empty () is not callable using argument types ( If empty is changed to mutable, the code compiles just fine, but if it's either const or inout, it fails. Given that the empty that filter's Result's empty is calling is std.array.empty (whose parameter is in), filter's Result's empty should be inferred as const, but it appears that it's not, since my class' empty can't be const due to the call to filter's Result's empty. My _guess_ would be that the problem stems from the fact that Result isn't templated (rather filter is templated, and Result is generated as part of that template), but I don't know. Regarldess, this is a major problem for constness and Voldemort types.

Note that this blocks const-ifying or inout-ifying some stuff in std.range and std.algorithm, making it harder to make them const-correct.

@safe, pure and nothrow aren't inferred in Voldemort types either.

@safe, pure and nothrow are supposed to be inferred on all templates, so if they're not inferred for Voldemort types, and they're templated (as they usually are), then it's definitely a bug (and I think that there's at least one open bug on that, but I'm not sure). But reading over this bug report, I'm not quite sure what I was thinking when I wrote it. const is _never_ inferred. Issue# 8407 is an enhancement for that which might solve this problem, but from what I can tell, there is no bug in dmd here. Either filter needs to be improved via static ifs, or we need something like issue# 8407 to be implemented in order to fix the problem that's occuring here, but I don't think that there's an actual compiler bug, and I don't know why I thought that there was at the time that I reported it.

I've added a new bug report: issue 10329