Compiler hints, inlining and syntax consistency

[Jakob Ovrum]

On Saturday, 28 December 2013 at 13:03:30 UTC, Ola Fosheim 
Grøstad wrote:
> 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.

No.

I have *no* idea where you got this idea from. D and its standard 
library follows in the footsteps of STL when it comes to the 
algorithmic complexity of primitives, and this has been an 
important tenet from *at least* the early days of D2. A few 
examples include std.container's maximum complexity requirement 
for primitives (including `length`) and the existence of 
std.range.walkLength. A recent example of enforcement includes 
the rejection of adding binary `in` functionality for 
non-associative arrays.

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

You could say this about any restriction in the type system.

(`@obsolete`? Did you mean `deprecated`?)