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.
