One thing about std.algorithm: you really seem to like using
compile-time strings as literals. However, this makes the use of
delegates harder. For example, to use a delegate, you need to do this
(quoted from your docs):
> int[] a = ...;
> static bool greater(int a, int b)
> {
> return a > b;
> }
> sort!(greater)(a); // predicate as alias
In my opinion, doing something like
> sort(a, (int a, int b) { return a > b; });
would be simpler and more intuitive than passing a delegate name as
template parameter. (The delegate literal syntax still could be
improved, though.)
Does std.algorithm work with closures at all? I see that the greater()
function in your example is marked as static. (Sorry, I didn't test it
myself.)
Using string mixins messes up syntax highlighting and the code is more
obfuscated. If you make an error in your predicate, random funny things
internal to the library implementation could happen, and the compiler
will spurt out indecipherable error messages for random modules (I guess
in this case, std.algorithm or std.functional). How will runtime
debugging work? Will the debugger be smart enough to point me to the
correct source code location, if there happens a segfault in my
predicate? I'm sure it could, if you used delegates instead.
Why did you make this so complex? What's your position on this? Do you
agree that there are problems, or are you happy with how it is?
Why did you choose to do it like this? Because it is shorter, or for
performance (avoid delegate call)? Does it enable some weird use cases,
which wouldn't be possible when using delegates?
Regarding performance: I don't think performance justifies all these
problems. Standard library functions should be as fast as possible, but
this goal should come second after robustness and simplicity.
Another problem is, that using string mixins seems to be quite
problematic, because they are mixed in in a different scope. If I'm not
mistaken, you can't do this:
> int foo(...) {...}
> sort!("foo(a, b);");
You might think that "sort!("a>b", a);" is elegant and short, but this
probably only works out in toy-examples.
And macros, which are supposed to magically cure all those problems,
were postponed to D3.0.
I'm also worried about compile times. You use nested templates with
string mixins, which only can be slower to compile than using e.g. the
builtin .sort. I don't know if this a problem, but in my opinion,
compile times are already high enough. Times will add up!
For one, I'm sure that this will generate an additional gazillion of
nearly useless linker symbols with very long names.
