Compiler hints, inlining and syntax consistency

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Saturday, 28 December 2013 at 11:58:48 UTC, Jakob Ovrum wrote:
> This is a terrible example - in D it's generally accepted that 
> such a `length` function should NOT be provided at all.

Correction: in the D-community it is generally accepted.

But the reasoning behind this is not sound, it puts the burden on 
the programmer when you can afford to use O(N). The reasoning is 
also flawed in general because the amortized/average performance 
of algorithms depends on the structure of the input. If you know 
that N tends to be below K on average then the performance hit is 
O(1) even if the complexity is O(N) on unbounded input on a 
turing-machine. And if we are going to be pedantic: all 
algorithms that terminates on a von Neuman-computing device are 
O(1) because you can always come up with a constant upper bound 
that holds for all physical computing devices.

@disable and (@obsolete) etc can safely be ignored for a sound 
program, it is a hint for the compiler to check the integrity of 
the logic, but it does not affect the semantics of a sound 
program. The same goes for unittests, pre conditions and post 
conditions etc.