Thread overview
uniform method naming convention for all lib std containers
Jul 14
mw
Aug 11
mw
July 14

Coming from this thread:

https://forum.dlang.org/thread/vardsjujllftwwumqfwz@forum.dlang.org

On Saturday, 13 July 2024 at 17:41:42 UTC, mw wrote:

on doc:

https://dlang.org/phobos/std_container_rbtree.html#.RedBlackTree

I cannot find any search method?! e.g. contains, canFind.

Is this a over look? Or there are such functions else where?

On Saturday, 13 July 2024 at 18:45:37 UTC, Dennis wrote:

>

It's the in operator:

https://dlang.org/phobos/std_container_rbtree.html#.RedBlackTree.opBinaryRight

But indeed, the documentation can be clearer about that.

On Sunday, 14 July 2024 at 02:01:44 UTC, Steven Schveighoffer wrote:

>

The functions are called equalRange (which gives you a range of all the elements that compare equal to the parameter), lowerBound (all elements less than the parameter), and upperBound (all elements greater than the parameter).

This was not my choice, my original dcollections implementation used a find function. It was a condition for having the type added to phobos.

I think for containers, it's better to have uniform method naming convention, either contains, canFind or in, so writing generic code (e.g. via D template) is easier.

July 15

On Sunday, 14 July 2024 at 18:02:57 UTC, mw wrote:

>

I think for containers, it's better to have uniform method naming convention, either contains, canFind or in, so writing generic code (e.g. via D template) is easier.

canFind is O(n) in time (need to slice the RBT first to get a range).
in should be defined when the time complexity is better than O(log n).

See in under Operations here:
https://dlang.org/phobos/std_container.html

July 15

On Monday, 15 July 2024 at 11:38:43 UTC, Nick Treleaven wrote:

>

canFind is O(n) in time (need to slice the RBT first to get a range).
in should be defined when the time complexity is better than O(log n).

Sorry, that should be O(log n) or better.

August 11

From this thread:

https://forum.dlang.org/post/warxdyxbpnbxwixgrxwm@forum.dlang.org

On Thursday, 5 February 2015 at 14:09:10 UTC, bearophile wrote:

>

Tobias Pankrath:

>

Works as designed: http://dlang.org/phobos/std_algorithm.html#.remove

Unfortunately it's one of the worst designed functions of Phobos:
https://issues.dlang.org/show_bug.cgi?id=10959

Bye,
bearophile

Hit this one today,

Has removeAt or removeAtIndex be added to the std lib?

BTW, for associative array, remove() is in-place; but here for std.algorithm.mutation.remove (keyword: mutation), one need to do

  array = array.remove(index);  // return a new container, not quite *in-place*

  // v.s.
  aa.remove(key);  // return bool (if it's removed)

This in-consistence is really bad.

On Sunday, 11 August 2024 at 13:13:02 UTC, Lance Bachmeier wrote:

>

You may want to create a new thread about this in General. If it's going to get changed, now is the time as they're working on updates to Phobos, but they're not going to see this post.

Also, this api re-work is related to this DIP: @mustuse as function return value annotation

https://github.com/mw66/mustuse/blob/main/mustuse.md