handful and interval

[Timon Gehr]

On 09/03/2012 08:53 PM, Jonathan M Davis wrote:
> On Monday, September 03, 2012 20:29:27 Timon Gehr wrote:
>> On 09/03/2012 08:01 PM, David Nadlinger wrote:
>>> On Monday, 3 September 2012 at 14:04:18 UTC, Andrei Alexandrescu wrote:
>>>>> A sufficiently smart compiler (tm) could
>>>>> optimize this to a efficient string "prefix switch statement" just as
>>>>> well…
>>>>
>>>> I agree. But then http://c2.com/cgi/wiki?SufficientlySmartCompiler.
>>>
>>> This is exactly my point: My feeling is that the increased complexity
>>
>> What complexity?
>
> He probably means that adding another function to do exactly what an existing
> function already does is complicating the library. The new function needs to
> bring enoug to the table to be worth it, and the syntactic change of allowing
> you to do
>
> if(value in handful(value1, value2, value3) {}
>

I am certainly not arguing for that one.

> instead of
>
> if(canFind([value1, value2, value3], value)) {}
>
> isn't worth that.
>
>>> by introducing a second syntax resp. a new special case (i.e. among) for
>>> such a simple operation is only worth it if it leaves no reason to
>>> revert to a hand-written replacement for performance reason,
>>
>> [ ].canFind( ) allocates on the GC heap without a sufficiently smart
>> compiler.
>
> That's then a performance issue which make may something like handful worth
> it, but Andrei seems to be arguing based on aesthetics rather than
> performance. And if you're arguing performance, I'd argue that the "in"
> solution is a bad one anyway, because it requires constructing and returning a
> struct, whereas you could just make what you're looking for the first argument.
> e.g.
>
> if(among(value, value1, value2, value3)) {}
>
> The syntax is less clear this way,

value.among(value1, value2, value3).

> and perhaps the syntactic convenience of
> the whole in idea outweighs the performcance cost there (particularly since it
> should still be cheaper than a heap allocation),

Basic function inlining usually works satisfactorily. Also, optimizing
non-bottlenecks is usually not worth the effort, but I still generally
avoid gratuitous allocations.

> but the only reason to argue against canFind that I can see is performance,

There are a couple unimportant ones like:
- "canFind"?
- it is unwritten law that x == 2 is preferred to 2 == x.
   (I have never experienced a bikeshedding discussion on that point,
   which is quite remarkable, as it is completely unimportant and there
   are multiple ways to do it.)
   this is much like x.among(2) vs [2].canFind(x);

> and if you're arguing
> performance, then I'm not sure that the in idea is necessarily the way to go.
>
> Regardless, the point is that there needs to be a practical reason for
> something like handful, not an aesthetic one.
>

I am arguing against pointless inefficiency. The motivation is almost 
purely aesthetic. (well, it *might* save time in the profiler, better
spent optimizing non-obvious inefficiencies and avoid the application
obtaining a sluggish feel, but I have absolutely no data to back that
up.)

I don't have an opinion on whether or not those specific functions
should be added, but Phobos is certainly lacking many simple functions.