Safer casts

Yigal Chripun yigal100 at gmail.com
Mon May 12 11:55:20 PDT 2008


Leandro Lucarella wrote:
> Janice Caron, el 11 de mayo a las 12:53 me escribiste:
>> On 11/05/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>>>  also, what if a doesn't actually have a "member" member? this is still
>>>  syntactically valid D code, but again I think the error would be
>>>  reported elsewhere.
>> On that point, I concede. The reporting of template errors could
>> certainly be improved. More than once I have wanted to see the "stack
>> trace" of errors, working back from the innermost, to the line of code
>> that ultimately triggered it.
>>
>> However, that it not an argument against templates, it is an argument
>> for improved error reporting. And hopefully, one day we'll get that.
>>
>> This is not the first time that you've argued that some feature or
>> strategy is bad because today's D compiler isn't good enough, but you
>> need to remember that tomorrow's D compiler will be better. That's
>> life on the cutting edge.
> 
> I think you can use Token Strings[1] in D2 to have better error reporting.
> It justs do lexical analisys, but it's something:
> 
> sort!(q{a > b})(array);
> 
> [1] http://www.digitalmars.com/d/2.0/lex.html
> 
this was already debated thoroughly, But I'll state my POV again. I
don't like the use of strings here at all. in any form.
D is a strongly typed language which I like and all those string tricks
although cool are bad IMO.

my issues with the use of this syntax:
a) what if I had a typo? what if i typed n instead of b (they are next
to each other on my keyboard)? your solution or any other string
solution cannot check this, since it is syntactically valid D code
inside the string.
b) if I want to compare q{a.member > b.member} there is no check that
member exists, or any other type checking. the error would occur in the
template code itself not in the string in both of the above examples.
c) what if I forgot to type the "q"?
d) most IDEs mark strings with a different color or something like that
so I treat them automatically as data and not code. ( this is a minor
issue, since IDEs could be made to work differently. but, my
sub-conscience response to strings as "not code" is harder to fix)

the only benefit to this is a slight performance benefit (though a good
compiler could provide the same performance by inlining a function call)
and a slightly shorter syntax which is a personal preference since you
type less but IMHO it becomes less readable and less obvious.
I prefer:
sort!((int a, int b) {return a.member > b.member;})(array);
this is more typing but provides all the checks and is more readable.
Think of the poor guy that will need to do maintenance on your code
years from now. now the string is a cool quick'n'dirty solution to the
problem at hand 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.
also the performance could be the same if I used a function instead of a
delegate allowing the compiler to inline it (hopefully).

since this is identical to:
sort(array, (int a, int b) {return a.member > b.member;});
there is no benefit in making it a template, IMO.

side note: using a feature of arrays in D this could be also rewritten as:
array.sort((int a, int b) {return a.member > b.member;});

Again, this is only my opinion (and I do prefer higher level solutions
and think the compler/linker can do a better job optimizing than I can).
you do not have to agree with this view, and there are already people
that disagree.



More information about the Digitalmars-d mailing list