Safer casts

[Bill Baxter]

Yigal Chripun wrote:
> 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"?

All of these things will cause compile-time errors.  You are right that 
the error reported may not point to the actual mistake in a very clear 
way, but you will get a syntax error right away.

The string gets turned into code via mixin(the_string) so if anything is 
not right with the code in the string, the compiler will barf.  Maybe 
you were thinking it was doing some sort of parsing of the string to 
generate a comparison function for you?  No. Just a raw mixin() in a 
scope in which 'a' and 'b' have been aliased to be the two elements 
being compared.

> 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 q{foo} thing was taken from Perl, so any IDE that can highlight perl 
should be able to highlight this in D with some tweaks.

--bb