I don't understand the message. It is a fact that size_t - int yields a size_t (unsigned) result. What may be signed here? The .length property? And what's the proper way to get a value in the range 0 .. length - x?

Right now D-Scanner doesn't do any semantic analysis, so it assumes that when you're doing a.length - 1 that a.length is probably size_t. If a.length happens to be 0 you'll end up with a segfault or range violation.

This reminds me of that weird discussion on the NG about what types are better: signed or unsigned.
But no matter what the type of length is, subtracting 1 will cause a range violation if it is 0. Actual valid negative indexing is very rare and not supported by D's range checks.
You are basically trying to prevent people from indexing array elements from a specific offset from the end (common practice in both arrays and files) as with arr[$-1], because the index could go out of range.

There's a reason that this is a warning and not an error. The purpose of this check is to have people check their code for the possibility of integer underflow. In several cases it gives false positive results.

Call me stubborn, but I don't see how we will work with a warning that triggers on 97% false positives. The ratio of "human error likeliness" / "false positive probability" needs to be a lot higher. What do we do about the code that triggers this warning after we verified its correctness? Usually you'd add a comment that disables the warning in this location or fix the code. But I don't see how this can be fixed and cluttering code with pragmas for something as trivial as taking a fixed negative offset from a length seems overkill.

You can turn this warning off.

Will do. :)

any updates on this? i would also like a way to turn off a warning for single lines only.