Should this work?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Jan 22 11:39:14 PST 2014


On 1/13/14 4:53 AM, Regan Heath wrote:
> On Fri, 10 Jan 2014 16:30:12 -0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> The way I see it one learns a name for an algorithm (low cognitive
>> load) and then uses it everywhere. This is not Go.
>
> Sure.  But, lets take an example: std.algorithm.canFind is more or less
> what you might call std.string.contains (which does not exist - instead
> we'd use indexOf != -1.. I think).

Well there's no perfection in this world :o).

> What is the harm in having an alias in std.string called contains which
> simply calls std.algorithm.canFind?

I think you can answer that for yourself. Just take the approach to its 
logical conclusion.

> Sure, it opens the door to someone using both canFind and contains on
> strings in their code.  So what?  Use of contains is more
> likely/intuitive for string related code, but both are intelligible.
> canFind will be more likely in generic code, where you would think of
> that generic algorithm name.
>
> It seems to me that people think of algorithms by different names in
> different contexts.  In the context of strings "contains" would make the
> most intuitive sense to the most people.

I agree that good names are difficult to find. I think you'd have a hard 
time with a "the more the merrier" stance.

> Side-issue.. from std.algorithm:
>
> bool canFind(alias pred = "a == b", R, E)(R haystack, E needle) if
> (is(typeof(find!pred(haystack, needle))));
> Returns true if and only if **value** can be found in range. Performs
> Ο(needle.length) evaluations of pred.
>
> What is **value** shouldn't that be needle?

Please file a bug or pull request. Thanks!


Andrei




More information about the Digitalmars-d mailing list