Safer casts

[Dee Girl]

Yigal Chripun Wrote:

> my issues with the use of this syntax:
> a) what if I had a typo?

algorithm.d(2528): Error: binaryFun(ElementType1,ElementType2) is not an lvalue
algorithm.d(2528): static assert  "void*"

Maybe the static assert message should be better. What if it says: Your comparison function is invalid? 

> what if i typed n instead of b (they are next
> to each other on my keyboard)?

Same message is written.

> 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.

Same message is written again.

> c) what if I forgot to type the "q"?

./test.d(9): found '}' when expecting ';' following 'statement'

At least now it is in your file ^_^

> 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 strings are short otherwise they anyway are better as functions. I do not think this could be a problem.

> 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 think it is very readable and obvious for reasons below.

> 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.

It is nice you can do both. You can put a string when it is small. You double the size of the code to write. When you have long comparison, you make it separate function. What I think is best of D when coming from other languages is that it gives so much options in such small core. 

> 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.

Here you may be wrong two times. First I tell from experience. I worked internship for a biotech company in Boston. I thought it will be research but it was so much work! ^_^ They used Perl and I did not know Perl when I began. But then I learned it and it has many nice things. One is sort which looks like this

sort { $a <=> $b } array;

I remember: first time I saw sort I understood how it works. The only odd thing was <=> but that means -1, 0 or 1 if a is less, equal or greater than b. I thought Perl has the most elegant definition of sort but now I think D has it.

Second you may be wrong because you think types help. They do not help in fact they may un-help. Write this

long array[] = ...;
sort!((int a, int b) {return a > b;})(array);

Sadly D lets long -> int conversion go through. Code will compile and run! But it gives wrong results for big numbers.

For sort type deduction is best. You should write

sort!((auto a, auto b) {return a > b;})(array);

And that works with int, long, float, string and all types that have >. It is the best writing of the intent of the sort. But I do not know how much type inference the D compiler can do.

> also the performance could be the same if I used a function instead of a
> delegate allowing the compiler to inline it (hopefully).

Good abstraction is the best. Performance is a good bonus ^_^

> 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.

I hoped I convinced you otherwise. After all effort still no understanding? Templates are best. They give you static and dynamic. Dynamic only gives dynamic.

> 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;});

Would be nice to allow array.sort!(cmp).

> 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.

Different views of same issues is good. But I see there are some things about which you are simply wrong because you do not understand how they work. Then I waste time explaining ^_^ Thank you, Dee Girl