Safer casts

[Ary Borenszweig]

Yigal Chripun escribió:
> 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)

I mostly agree with you. The problem with defining these things is 
strings is that... they are strings! They are not bind to symbols in the 
language. So in that sense you can't expect any help from an IDE: no 
autocompletion, no refactor, no go to definition, no nothing.

If you take a look at two top languages of the moment (C# and Java) you 
can see the designers take careful steps to make the language good, 
eficcient, and IDE-enabled (making an IDE for those languages is 
relatively easy).

Even for extension methods C# makes a lot of restrictions: they must be 
defined in a static class, and the first parameter must have a "this". 
In that way, an IDE must only search in static classes, and in those, 
just the methods that have a "this". In D, if there are no restrictions, 
you could potentially need to make a big search in order to see where an 
extension method can or cannot be proposed.