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