Safer casts

[Dee Girl]

Yigal Chripun Wrote:

> Your example does use delegates.
> the difference is this:
> say you have two delegates you pass to sort, for example you sort one
> array in ascending order, and another in descending order. the template
> solution will generate two almost identical sort functions with the only
> difference that one sort instance calls internally the first delegate,
> and the second instance calls the second. you get 4 functions. without
> the template, you get one sort function and two delegates, so only 3
> functions.

This should be good for the standard library. It is the most flexible approach. You can always do what you want in one line:

void mysort(int array[], bool delegate comp(int, int))
{
    sort!(comp)(array);
}

Now you can call mysort many times and there is only one version of std.sort (if I understand it correctly).

But think what if your mysort is the only implementation given in the standard library. Maybe sometimes it is too slow for your program. What do you do?

void fastsort!(alias comp)(int[] array)
{
    bool dg(int a, int b) { return comp(a, b); }
    mysort(array, dg);
}

This will not be faster at all ^_^. As a friend said: You can build a dynamic library from a static one but not inverse. Things only stack one direction. I think it is good the way sort is now in the standard library, it offers the maximum possible and opens all options. It is very impressive for someone coming from many other language.

> Now, when you use a string with the template, the sort will contain the
> code itself inline to the sort instance so it "saves" you a function
> call. IMO, the string solution is not clean ( C MACROs? )and while for
> simple cases it could save you a function call it's premature
> optimization IMO.

To me it looks very convinent! 

> Also, if I use delegates, I can't see how a template
> can save that function call. so it just bloats my executable with
> unneeded copies of sort.

You can use mysort above. It is my first contribution to D. ^_^

> I hate when library code forces me to this. I think the programmer knows
> his code better than the library writer and should be able to choose
> himself whether he needs to use a compile time solution to save function
> calls or a run-time solution to prevent unnecessary executable bloat.
> this optimization should be made by the programmer and _not_ the library
> writer. This solution does not give me that freedom.

It looks like you understand the exact oposite. std.sort gives you all freedom, anything else would give less. I have studied many languages but none offers the same flexibility. Functional languages force you to copy. Java, Smalltalk and C# force virtual calls on comparisons. C++ force you to go outside your function and write the comparison even simple as a.member < b.member! D is the best and std.algorithm very elegant.

> this solution is a classic STL piece of code, BUT, the main difference
> is that for C++ this is probably the only reasonable solution as C++
> doesn't have delegates. this is why when coding for D I urge people to
> rethink their solution instead of just doing what is best in C++ (or any
> other preferred language of the library writer). This is a prime example
> why the C++ solution is wrong for D.

The other rant you wrote and the interesting discussion with Janice are good to read. But there is little objective points you bring. I see you do not like anything like C++ and then you go back and try to make arguments.

One objective point is you like a container hierarchy. I have worked with them and they can be useful. But like with mysort the same argument works. You can build a hierarchy of containers on top of fast containers. But not the inverse. Dee Girl