ch-ch-changes

[grauzone]

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.