Proposal for Implicit Conversion of Types

[Rioshin an'Harthen]

"Don Clugston" <dac at nospam.com.au> wrote in message 
news:e104fr$1hgk$1 at digitaldaemon.com...
> Rioshin an'Harthen wrote:
>> Proposal for Implicit Conversion of Types
>> =========================================
>>
>> This proposal spawned from the discussion "No more implicit
>> conversion real->complex?!" between myself and Don Clugston
>> after the change introduced in D version 0.150.
>
>> archetype | types (in order of smallest to largest)
>> -----------+-----------------------------------------
>>  void      | void
>>  bool      | bool
>>  cent      | byte, short, int, long, cent
>>  ucent     | ubyte, ushort, uint, ulong, ucent
>>  real      | float, double, real
>>  ireal     | ifloat, idouble, ireal
>>  creal     | cfloat, cdouble, creal
>>  dchar     | char, wchar, dchar
>
>
> Very well presented!

Thank you. :)

> There's one aspect that I think could be a problem -- conversions between 
> signed and unsigned types.
> As written, that would mean that ushort -> ulong is preferred over 
> ushort ->short. Since the language currently allows short and ushort to be 
> interchanged without error (unless you enable warnings), I don't think the 
> lookup rules can be different to that.
>
> So I think that right now, the cent/ucent categories will need to be 
> combined: if more than one such conversion is possible, it's an error.
> Otherwise we end up in the 'should signed/unsigned conversions be an 
> error' debate which has historically been unfruitful.

True, it is a problem with this proposal. It is not enough to add implicit
semantic-changing conversions between the cent and ucent archetypes,
since it would still prefer the widening conversions.

However, I feel doubtful about combining the archetypes together. I would
actually prefer to force signed to unsigned conversions to be explicit, 
since
negative numbers can be "lost". Unsigned to signed is not that much of a
problem, since (unless the type is ucent), it is possible to convert to a 
wider
type, eg. ushort to int.

Still, I am willing to allow the combination of those archetypes, even 
though
I feel the doubt I mentioned. It would allow existing code to continue 
working,
which is one of the main intents of the proposal, although I took some 
liberty
with the boolean type in this case.