Safer casts

[Yigal Chripun]

Janice Caron wrote:
> On 12/05/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>>  I prefer:
>>  sort!((int a, int b) {return a.member > b.member;})(array);
> 
> ints don't have a member variable called .member, so presumably, you
> must have meant something like
> 
>     class C { int member; }
>     C[] array;
>     sort!(C a, C b){return a.member > b.member;})(array);
> 
right. Thanks for the fix. I'm not that good with examples.
> 
>>  this is ... more readable.
> 
> No it isn't. ;-)
> 
> 
>>  but in the future that other programmer will have no
>>  idea what those "a" and "b" are. especially since you didn't write the
>>  types of them.
> 
> Incorrect. "a" and "b" are the placeholders for the things being
> compared. This is well documented in the documentation for sort. The
> only way anyone could not know what the "a" and "b" were would be if
> they hadn't RTFM.
> 
> 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.
also, why do I have to go and search the docs if the code is in front of me?
at my work we have a very large code base in Fortran, which has to be
linked to every program. I don't know Fortran and don't need to since I
use c++. all those things there that where so obvious to the Fortran
coders 15 years ago look to me like raw binary code. they've used
various low-level tricks that no one understands and that aren't
properly documented. if I get a linking error with those Fortran objects
I could spend days trying to figure it out. I can look at the code and
try to understand what's going on, but I don't know Fortran so every bit
of readability helps. replace Fortran with D in this (real life) example
and try to understand that it's not so easy as you make it.
> 
> 
>>  there is no benefit in making it a template, IMO.
> 
> The benefit is choice.

choice of what? You've said so yourself, both templated and
non-templated versions of the sort-with-delegate are identical.
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.

I guess I wouldn't object as much if D's syntax for calling templated
code weren't different from regular functions which would bring a more
uniform syntax (take a look at macros in Nemerle).
Does it irritate only me? maybe I am the odd one here. I just don't want
to care if one array function is a generic template, while another
isn't. 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.