Compiler hints, inlining and syntax consistency

[Jakob Ovrum]

On Saturday, 28 December 2013 at 19:11:14 UTC, Ola Fosheim 
Grøstad wrote:
>> But the disadvantages are serious, most notably generic code 
>> that uses `in` and assumes it has some complexity guarantee 
>> would experience a blow-up in complexity when an array is 
>> passed.
>
> Ok, I agree with this for simple operators like +, -, * etc. 
> Whether 'in' is a simple operator probably depends on what you 
> are used to from other languages.

That's fair enough. I think the safe choice is to wait and see 
how it unfolds in libraries to come.

>> Further, adding syntax sugar to such an operation sends the 
>> wrong signal and is thus asking for trouble during code 
>> maintenance - initially the array might have been small and 
>> use of `in` judicious, but later down the line the array grows 
>> while the use of `in` is preserved because it *looks* low-cost
>
> Depends on where you come from. I think it is quite common in 
> Python code to test 'in' for short immutable (literal) arrays, 
> e.g. "if action in ['say','talk','shout']:"
>
> I think it is reasonable to accept that, because the code 
> becomes much easier to read if you do lots of text processing. 
> So it depends on what kind of programs you tend to write. It 
> has no place in a 3D engine, but is useful in text based 
> adventure games.

For array literals it's not such a bad idea, and was recently 
topical in the assessment of `std.algorithm.among`[1]. However, 
as elaborated upon in the linked PR, I think the library solution 
is superior for D.

[1] https://github.com/D-Programming-Language/phobos/pull/1787