Safer casts

[Yigal Chripun]

Janice Caron wrote:
> On 12/05/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>>  > The type of a is the type of the array element. This is obvious.
>>
>> again, obvious to you, not that dude five years from now reading your
>>  code. documented is not the same as compiler checked, and we both know
>>  that documentation could get out of sync with the code.
> 
> I'm talking about the documentation for std.algorithm.sort. What are
> you talking about?
> 
> It is perfectly reasonable to expect that anyone using
> std.algorithm.sort will have read the documentation on how to use it.
> 
> 
>>  also, why do I have to go and search the docs if the code is in front of me?
> 
> You don't. You learn how to use std.algorithm.sort, and then you use
> it, going back to the docs only occasionally.
> 
> It's the same with anything. If I want to use a std::vector in C++,
> I'd better have read up on what std::vectors are and how to use them
> first.
> 
> So yes, it's obvious what the "a" and "b" mean.
> 
> 
> 
>>> The benefit is choice.
>>  choice of what?
> 
> Of everything. Of having it do whatever you want, whatever that is.
> 
> 
>> You've said so yourself, both templated and
>> non-templated versions of the sort-with-delegate are identical.
> 
> I have said no such thing! (And I take great offense at being misquoted)
> 
> I may have said that *one particular instantiation* of the template is
> identical to the delegate version. Fair enough. But I can also make
> different instantiations.
> 
I am talking about *one particular instantiation* of the template!
> 
>>  you want those string templates (which i don't like) than fine, define
>>  them as templates and i won't use them. but the version with the
>>  delegate is needlessly a template.
> 
> There /is/ no "version with the delegate". But you can /make/ a
> version with a delegate out of the template.

Again, this is exactly what I want. this should be in the standard library.
> 
> And those string parameters are brilliant! Today I wanted to strip out
> all underscores from a string. So I sat down to write the function -
> it's not really hard, after all - but then, with a flash of
> inspiration, I realised the function already exists. It is:
> 
>     filter!("a != '_'")(s);
> 
> That is just /so/ amazing.
> 
for string manipulation I agree that this is useful.
> 
> 
>>  ideally (not possible in current D) both forms should have the
>>  same syntax, so the end user (me) doesn't need to know nor care about
>>  what sort of implementation was chosen.
> 
> You haven't heard of aliases or wrapper functions then?

I meant possible *directly* not via wrappers.

example time:
I want the following API:
(I don't care now for the internal implementation and the wrapper
functions/aliases should be provided by the standard library)

array.sort; //same as array.sort(ASC);
array.sort(DESC);
array.sort(someStaticComperator);
array.sort(aDelegateComperator);
array.someOtherfunction(params);
List.sort;
someOtherCollection.sort;
int.sort; //compile time error, no sort method for int
etc...