On Wed, 28 Jan 2009 11:57:43 +0100, grauzone <n...@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.
