Safer casts

[Yigal Chripun]

Bill Baxter wrote:
> 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

i know it's a string mixin. my personal issue with it is indeed the
wrong errors. I also dislike perl. I like Smalltalk (and Ruby) though.
also I'd prefer an array.sort(comp); over sort!(comp)(array); but,
AGAIN, that's just MY personal preference (since I like the code blocks
of Ruby/Smalltalk).
it's simpler from the end user's POV.