On Thursday, 21 January 2016 at 01:11:19 UTC, Andrei Alexandrescu wrote:
> On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:
>> 2. The index of minimum or maximum element, mostly using plain array as
>> a range.  I write "a.length - a.minPos.length", and it looks completely
>> unintuitive.  Additionally, when compiling to 64 bits, I usually still
>> want an int to use with other ints around (longs are overkill most of
>> the time), and the cast adds more clobber.  Again, is there a better way
>> to express that?
>
> No better way currently. We could add (min|max)Index but I like (min|max)Pos quite a bit. They offer more flexibility for non-random access ranges.

But (min|max)(Index|Key) offer different type of flexibility as those make sense for associative containers.

On Thursday, 21 January 2016 at 02:36:05 UTC, Ivan Kazmenko wrote:
> An alternative would be to define min(one argument) to just be that argument.  That would be consistent with what we have now, but violates the principle of least astonishment for newcomers: why would min ([3, 1, 2]) return [3, 1, 2] and not 1?  Currently, it just does not compile.

As a newcomer to the language, and as a reader of https://dlang.org/phobos/std_algorithm_comparison.html#min which states "Iterates the passed arguments and returns the minimum value." my intuitive understanding would be that yes of course min(x) returns x.
However the above could of course also be reworded as "Iterates the passed list of arguments and returns the minimum value." to be even more clear about it NOT iterating individual arguments but the argument list as a whole :-)

If I were to be a newcomer to programming in general this might be confusing, though. However, it's certainly consistent and easy to wrap your head around and also what I would have expected it to do the first time I came across the function.

On Thursday, 21 January 2016 at 12:17:26 UTC, default0 wrote:
> On Thursday, 21 January 2016 at 02:36:05 UTC, Ivan Kazmenko wrote:
>> An alternative would be to define min(one argument) to just be that argument.  That would be consistent with what we have now, but violates the principle of least astonishment for newcomers: why would min ([3, 1, 2]) return [3, 1, 2] and not 1?  Currently, it just does not compile.
>
> As a newcomer to the language, and as a reader of https://dlang.org/phobos/std_algorithm_comparison.html#min which states "Iterates the passed arguments and returns the minimum value." my intuitive understanding would be that yes of course min(x) returns x.
> However the above could of course also be reworded as "Iterates the passed list of arguments and returns the minimum value." to be even more clear about it NOT iterating individual arguments but the argument list as a whole :-)
>
> If I were to be a newcomer to programming in general this might be confusing, though. However, it's certainly consistent and easy to wrap your head around and also what I would have expected it to do the first time I came across the function.

Still, looks like Java, C# and Python have min work this way: given a single argument which is a collection, it returns the minimum in that collection, not the collection itself.  A Python example:

min ([1])  // 1
min ([2, 1])  // 1
min ((([1, 2], [2, 3])))  // [1, 2]
min ((([1, 2])))  // 1
min ((([1, 2],),))  // ([1, 2],)

In Python, the what happens is also tricky:

def g(): return (1, 2)  // tuple of two values
g()  // (1, 2)
min (g())  // 1 from tuple
min (*g())  // 1 from expanded tuple

def f(): return (1,)  // tuple of a single value
f()  // (1,)
min (f())  // 1
min (*f())  // error, cannot expand

On Wednesday, 20 January 2016 at 17:29:28 UTC, H. S. Teoh wrote:
> On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
>> This is one of those cases in which we were pedantically right to not add them, but their equivalents look like crap.
>
> I don't like this.  I'd much rather we rename those functions to be something more generic.  After all, minPos is a horrible name when the predicate has nothing to do with minimum values. What about extremumPos? (Though that's rather ugly to type.)

 maxCount sounds too much like it's suppose to be a function in SQL querying, and minCount... ugg... now I wonder what in the world we're talking about.

From algorithm.d:
> int[] a = [ 2, 3, 4, 1, 2, 4, 1, 1, 2 ];
> // Minimum is 1 and occurs 3 times
> assert(a.minCount == tuple(1, 3));
> // Maximum is 4 and occurs 2 times
> assert(a.maxCount == tuple(4, 2));
>
> // Minimum is 1 and first occurs in position 3
> assert(a.minPos == [ 1, 2, 4, 1, 1, 2 ]);
> // Maximum is 4 and first occurs in position 2
> assert(a.maxPos == [ 4, 1, 2, 4, 1, 1, 2 ]);

These unittests make it completely clear what it wants to do. I'd almost say lowestCount and highestCount would almost be better, but i am not sure. or just unitCount? Or countOf and posOf? which make a lot more sense when instantiated: So a.countOf!("a < b")?

 I'm seriously behind on all of this.

On 01/21/2016 08:42 AM, Era Scarecrow wrote:
> I'd almost say lowestCount and highestCount would almost be better, but
> i am not sure.

minCount is already a given. -- Andrei

On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu wrote:
> On 01/21/2016 08:42 AM, Era Scarecrow wrote:
>> I'd almost say lowestCount and highestCount would almost be better, but
>> i am not sure.
>
> minCount is already a given. -- Andrei

countMost!less and posMost!less

On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu wrote:
> On 01/21/2016 08:42 AM, Era Scarecrow wrote:
>> I'd almost say lowestCount and highestCount would almost be better, but I am not sure.
>
> minCount is already a given. -- Andrei

 I have a slight problem where I'm not already familiar with most of the standard library functions (D, libc, etc) that are usually available. This usually means I have a naive approach and/or naming convention to what's already been in place 15+ years.

 Of course when I do take the time to go through the libraries and documentation I'll say 'oohhh that's cool!'; But because I'm not actively using it I'll promptly forget it :(