Andrei Alexandrescu via Digitalmars-d digitalmars-d at
Sun Feb 15 13:23:14 PST 2015

On 2/15/15 12:29 PM, Steve D wrote:
> Well, it provoked a little discussion, and I remain unconvinced.
> Why differentiate between 'in' for an associative-array and 'in' for an
> unordered sequence/array? This implies that the programmer is an idiot who
> believes that trawling through an unordered sequence is as fast as a
> dictionary
> key lookup. Such programmers should not be coding, never went to school
> or are
> probably one of those new kids who only fanny-about with javascript
> frameworks.
> The point is that python's 'in' or 'index()' .. whatever, give the fastest
> implementation for the underlying data type. (the same as canFind will
> probably
> give the quickest result)
> The coder can trust this, and then use the common idiom instead of
> wondering
> (as a new D coder) -  is it an 'in'?, a 'canFind'? an 'indexOf'? a
> 'countUntil'?
> Is it builtin? Is it in std.algorithm? What's the typical lookup for
> this seq?
> The second point is that common idioms across datatypes, make for
> consistent,
> simpler intuitive coding, whilst also trusting that the language
> implementors
> have spent time optimizing the different underlying implementations.
> Think about new D coders, or those coming from other languages or planets.
> Apparently this has all been done to death so, yeah, like whatever..
> Arguing for inconsistency means you are all retarded :)

We're good as we are. D's standard library goes for a proportional 
response in syntax space to the cost of search. This is STL's influence, 
where this approach has worked better than "best effort under uniform 
syntax" (e.g. std::distance()).

std.container follows the same convention, see e.g. APIs with "linear" 
in their name.

This is not enforced or prescriptive. User code is free to choose 
different conventions.

The one possible change would be to allow "in" with statically-sized 
arrays, under the assumption that the amount of data searched is fixed 
and proportional to the size of the program.


More information about the Digitalmars-d mailing list