On 1/9/2014 10:37 PM, Manu wrote:
> How long did it take to get him there? I suspect he made the leap only when a
> particular task that motivated him to do so came up.

Pretty much true. And it was worth it :-)

On Monday, 13 January 2014 at 12:53:08 UTC, Regan Heath wrote:
> or less what you might call std.string.contains (which does not exist - instead we'd use indexOf != -1.. I think).

Just a side track:

What I dislike about return values as error-indicators is that they are arbitrary so you have to memorize "-1", "0", null, throws…

I think it is often useful to have user-supplied default and sensible naming like having functions that allow testing for "0","false","null" as failure ending with "OK" in their name. And functions that throws ought to have some kind of assertive name like "validate" or a name that explicitly hints at exceptions.

"-1" is really a horrible error value since it fails the "boolean test", and e.g. if you want the non-query part of an url, you want string length to be the "not found value" when searching for "?", not -1:

"http://server.com/page"
"http://server.com/page?query=xyz"

On Wed, 22 Jan 2014 19:39:14 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/13/14 4:53 AM, Regan Heath wrote:
>> On Fri, 10 Jan 2014 16:30:12 -0000, Andrei Alexandrescu
>> <SeeWebsiteForEmail@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.

You mean the best possible name in all contexts, yes!  :p

Seriously, I am not suggesting we do this for all functions all the time, but just enough so that most users find what they expect to find and get what they expect to get, where it doesn't break D's philosophy of not doing inefficient things for the sake of being generic of course.

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

This.  Not my position.  Rather I am suggesting we identify individual omissions (like std.string.contains) and add an alias.  So that people don't have to struggle quite so much when switching to D.  The lower the bar and all that..

>> 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!

Bug filed.

R

On 1/23/14 8:06 AM, Regan Heath wrote:
> This.  Not my position.  Rather I am suggesting we identify individual
> omissions (like std.string.contains) and add an alias.  So that people
> don't have to struggle quite so much when switching to D.  The lower the
> bar and all that..

Ionno. Just look at the current morass with https://github.com/D-Programming-Language/phobos/pull/1875. We have two names for the same function "canFind" and "any". Then we want to deprecate one, but look at how much impact it's having on Phobos alone. Are you sure you want to add a _third_?


Andrei

On 2014-01-23 21:53, Andrei Alexandrescu wrote:

> Ionno. Just look at the current morass with
> https://github.com/D-Programming-Language/phobos/pull/1875. We have two
> names for the same function "canFind" and "any". Then we want to
> deprecate one, but look at how much impact it's having on Phobos alone.
> Are you sure you want to add a _third_?

Personally I would expect "any" to take a predicate and return "true" if it can find any matching element. If a predicate is not supplied it would behave as the opposite of "empty".

I would expect "contains" to take a element and check if it exists in the range.

I think "canFind" is just a weird name.

-- 
/Jacob Carlborg

On Friday, 24 January 2014 at 08:21:12 UTC, Jacob Carlborg wrote:
> Personally I would expect "any" to take a predicate and return "true" if it can find any matching element. If a predicate is not supplied it would behave as the opposite of "empty".

+1

> I would expect "contains" to take a element and check if it exists in the range.

+1

> I think "canFind" is just a weird name.

+1

I also think that contains/canFind/etc ... should get advantage of sorted ranges to speed up their searches (now it seems they don't!)

On Friday, 24 January 2014 at 08:21:12 UTC, Jacob Carlborg wrote:
> On 2014-01-23 21:53, Andrei Alexandrescu wrote:

> I would expect "contains" to take a element and check if it exists in the range.
>
> I think "canFind" is just a weird name.

I agree on the latter point. As for "contains"... Well, if we address the terminology, we should consider that ranges are not really containers, therefore "contains" would be slightly incorrect. Perhaps "encounters" or "isWithin"? :)

On a serious note though, "contains" is leagues ahead of "canFind".

On Fri, 24 Jan 2014 08:21:12 -0000, Jacob Carlborg <doob@me.com> wrote:

> On 2014-01-23 21:53, Andrei Alexandrescu wrote:
>
>> Ionno. Just look at the current morass with
>> https://github.com/D-Programming-Language/phobos/pull/1875. We have two
>> names for the same function "canFind" and "any". Then we want to
>> deprecate one, but look at how much impact it's having on Phobos alone.
>> Are you sure you want to add a _third_?
>
> Personally I would expect "any" to take a predicate and return "true" if it can find any matching element. If a predicate is not supplied it would behave as the opposite of "empty".

Yep, this is what the C# version does.

> I would expect "contains" to take a element and check if it exists in the range.

Except in the case of string, where we also want an overload taking more than a single element aka a substring.

> I think "canFind" is just a weird name.

Me too, but it makes sense as a "generic" name I think.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 23 Jan 2014 20:53:01 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/23/14 8:06 AM, Regan Heath wrote:
>> This.  Not my position.  Rather I am suggesting we identify individual
>> omissions (like std.string.contains) and add an alias.  So that people
>> don't have to struggle quite so much when switching to D.  The lower the
>> bar and all that..
>
> Ionno. Just look at the current morass with https://github.com/D-Programming-Language/phobos/pull/1875. We have two names for the same function "canFind" and "any". Then we want to deprecate one, but look at how much impact it's having on Phobos alone. Are you sure you want to add a _third_?

Not *quite* the same.  Any is/was in the same module as canFind and for use in the exact same context.  A string specific "contains" would only be used in the context of string parsing.  If contains existed in std.string then it would be unusual for anyone to use canFind on a string (in a string only context).

That's what I'm suggesting, not adding more generic aliases/names for existing functions (as Any was) but adding specific names in specific contexts for otherwise generic functions with odd generic names, like canFind.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Fri, 24 Jan 2014 08:36:07 -0000, Stanislav Blinov <stanislav.blinov@gmail.com> wrote:

> On Friday, 24 January 2014 at 08:21:12 UTC, Jacob Carlborg wrote:
>> On 2014-01-23 21:53, Andrei Alexandrescu wrote:
>
>> I would expect "contains" to take a element and check if it exists in the range.
>>
>> I think "canFind" is just a weird name.
>
> I agree on the latter point. As for "contains"... Well, if we address the terminology, we should consider that ranges are not really containers, therefore "contains" would be slightly incorrect. Perhaps "encounters" or "isWithin"? :)

This is the complete opposite of the point I was trying to make :p

I don't want a generic name/function, or a range specific name/function we already have the generic one, and probably a range one, I want a string specific one - in this particular example - with a name people will expect to find (pun intended) when doing string manipulation.

> On a serious note though, "contains" is leagues ahead of "canFind".

I think it depends on the context.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/