ch-ch-changes

[Max Samukha]

On Wed, 28 Jan 2009 11:57:43 +0100, grauzone <none at example.net> wrote:

>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.)

D2 accepts delegate literals for alias template parameters:
sort!((int a, int b) { return a > b; })(a);

>
>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.)

You could use a temporary:

bool delegate(int, int) getGreater()
{
   return (int a, int b){ return a > b; }; 
}

auto pred = getGreater();
sort!(pred)(a);

>
>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. 

That's a good question. 

But I still prefer Andrei's solution over bearophile's because if I
wanted to save a couple of template instantiations I could wrap the
algorithms to use a delegate reference/function pointer. With
bearophile's implementation, the oposite seems to be impossible.