unsigned policy (implicit conversions for complex?)

[Derek Parnell]

On Mon, 12 Feb 2007 18:59:49 -0800, Walter Bright wrote:

> Derek Parnell wrote:
>> On Mon, 12 Feb 2007 16:03:14 -0800, Andrei Alexandrescu (See Website For
>> Email) wrote:
>> 
>>> http://erdani.org/d-implicit-conversions.pdf
>>  
>>> Did I forget something?
>> 
>> Characters are not numbers. 
> 
> That's an enticing point of view, and it sounds good. But Pascal has 
> that view, and my experience with it is it's one of the reasons Pascal 
> sucks.
> 
> Examples:
> 
> 1) converting text <=> integers
> 2) converting case
> 3) doing compression/encryption code
> 4) using characters as indices (isspace() for example)
> 
> Take away the implicit conversions, and such code gets littered with 
> ugly casts.

D has a neat property sub-system already. For example, it is used to get at
the underlying implementation data for arrays. So why not call spade a
spade and stop helping bug-making. You have recently done this with
implicit conversion from array pointers and arrays. If characters had a
property called, for example, ".numval" then ugly casts would not be needed
*and* such special character usage will be documented.

In the examples above, (1) and (2) are really far to complex in the unicode
world to simply perform arithmetic on the implementation value of a
specific character to get a result. They really need table look ups or
similar to do it well. As you know, not all strings are ASCII.

Compression/encryption is best done using unsigned bytes so I would cast
the 'string' to that. And by doing so, it highlights to the code reader
that something special is going on here.

   ubyte[] res = encrypt(cast(ubyte[]) stringdata );

Note the result of encryption/compression is most certainly not going to be
a valid UTF string so a ubyte[] would be a better choice.

Finally, the fourth example lends itself to the .numval property very
nicely ...

  ulong a = char_prop[ somechar.numval ];


If our aim is to make writing and reading D code as easy as possible, while
also helping the coder to implement their algorithms correctly, then the
compiler should at least highlight inappropriate implicit conversions such
as ...

   return lowchar + 'A' - 'a';

If one really feels that they must do this then at least let the coder
reader know that this is odd.

  return lowchar + 'A'.numval - 'a'.numval;

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
13/02/2007 2:27:39 PM