Andrei Alexandrescu (See Website For Email) wrote:
> 
> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly.

Exactly.

> Walter is willing to fix D in accordance to that
> rule, which would yield an implicit conversion graph as shown in:
> 
> http://erdani.org/d-implicit-conversions.pdf
> 
> Notice that there is no arrow e.g. between int and uint (loss of meaning), or between int and float (loss of precision). But there is an arrow from int and uint to double, because double is able to represent them faithfully.
> 
> If we are nice, we may convince Walter to implement that soon (maybe in 1.006?) but it must be understood that the tighter rules will prompt changes in existing code.

That's fine with me.  Many of us have been asking for this for quite a while.


Sean

Andrei Alexandrescu (See Website For Email) wrote:
> Henning Hasemann wrote:
>> I know this is a more general questions as it applies to C and C++ as well,
>> but somewhere I have to ask and actually D is what Im coding in:
>>
>> Should one try to use uint in favor of int whenever one knows for sure the value
>> wont be negative? That whould be a bit more expressive but on the other hand
>> sometimes leads to type problems.
>> For example, when having things like this:
>>
>> T min(T)(T a, T b) {
>>   return a < b ? a : b;
>> }
>>
>> Here you whould need to ensure to cast values so they share a common type.
>>
>> How do you code? Do you use uint whenever it suitable reflects the data to
>> store (eg a x-y-position on the screen) or only when necessary?
> 
> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
> 
> http://erdani.org/d-implicit-conversions.pdf
> 
> Notice that there is no arrow e.g. between int and uint (loss of meaning), or between int and float (loss of precision). But there is an arrow from int and uint to double, because double is able to represent them faithfully.
> 
> If we are nice, we may convince Walter to implement that soon (maybe in 1.006?) but it must be understood that the tighter rules will prompt changes in existing code.
> 
> To answer your question, with the new rules in hand, using unsigned types will considerably increase your expressiveness and your ability to detect bugs statically. Also, by the new rules ordering comparisons between mixed-sign types will be disallowed.
> 
> 
> Andrei

Does this mean that int would no longer implicitly convert to bool?
For example, the following would not longer compile.

  int i = 1;
  if (i) {}

This would instead give an error something like "no implicit conversion from int to bool".

If this were the case, wouldn't it make the expression (a < b < c) illegal, as is being discussed in another thread. Since "a < b" would result in a bool, but bool < int is not a legal comparison.

Thanks,
  Bradley

On Wed, 07 Feb 2007 22:46:02 -0800, Bradley Smith wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
>> Henning Hasemann wrote:
>>> I know this is a more general questions as it applies to C and C++ as
>>> well,
>>> but somewhere I have to ask and actually D is what Im coding in:
>>>
>>> Should one try to use uint in favor of int whenever one knows for sure
>>> the value
>>> wont be negative? That whould be a bit more expressive but on the
>>> other hand
>>> sometimes leads to type problems.
>>> For example, when having things like this:
>>>
>>> T min(T)(T a, T b) {
>>>   return a < b ? a : b;
>>> }
>>>
>>> Here you whould need to ensure to cast values so they share a common type.
>>>
>>> How do you code? Do you use uint whenever it suitable reflects the
>>> data to
>>> store (eg a x-y-position on the screen) or only when necessary?
>> 
>> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
>> 
>> http://erdani.org/d-implicit-conversions.pdf
>> 
>> Notice that there is no arrow e.g. between int and uint (loss of meaning), or between int and float (loss of precision). But there is an arrow from int and uint to double, because double is able to represent them faithfully.
>> 
>> If we are nice, we may convince Walter to implement that soon (maybe in 1.006?) but it must be understood that the tighter rules will prompt changes in existing code.
>> 
>> To answer your question, with the new rules in hand, using unsigned types will considerably increase your expressiveness and your ability to detect bugs statically. Also, by the new rules ordering comparisons between mixed-sign types will be disallowed.
>> 
>> Andrei
> 
> Does this mean that int would no longer implicitly convert to bool? For example, the following would not longer compile.
> 
>    int i = 1;
>    if (i) {}
> 
> This would instead give an error something like "no implicit conversion from int to bool".

I hope it would cause this error. Unless the compiler treats this a
shorthand for if (i != 0) {}

> If this were the case, wouldn't it make the expression (a < b < c) illegal, as is being discussed in another thread. Since "a < b" would result in a bool, but bool < int is not a legal comparison.

Not so I think, because the bool would be converted to an int then the comparison would take place.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
8/02/2007 5:52:03 PM

Bradley Smith wrote:
> 
> Andrei Alexandrescu (See Website For Email) wrote:
>> Henning Hasemann wrote:
>>> I know this is a more general questions as it applies to C and C++ as well,
>>> but somewhere I have to ask and actually D is what Im coding in:
>>>
>>> Should one try to use uint in favor of int whenever one knows for sure the value
>>> wont be negative? That whould be a bit more expressive but on the other hand
>>> sometimes leads to type problems.
>>> For example, when having things like this:
>>>
>>> T min(T)(T a, T b) {
>>>   return a < b ? a : b;
>>> }
>>>
>>> Here you whould need to ensure to cast values so they share a common type.
>>>
>>> How do you code? Do you use uint whenever it suitable reflects the data to
>>> store (eg a x-y-position on the screen) or only when necessary?
>>
>> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
>>
>> http://erdani.org/d-implicit-conversions.pdf
>>
>> Notice that there is no arrow e.g. between int and uint (loss of meaning), or between int and float (loss of precision). But there is an arrow from int and uint to double, because double is able to represent them faithfully.
>>
>> If we are nice, we may convince Walter to implement that soon (maybe in 1.006?) but it must be understood that the tighter rules will prompt changes in existing code.
>>
>> To answer your question, with the new rules in hand, using unsigned types will considerably increase your expressiveness and your ability to detect bugs statically. Also, by the new rules ordering comparisons between mixed-sign types will be disallowed.
>>
>>
>> Andrei
> 
> Does this mean that int would no longer implicitly convert to bool?
> For example, the following would not longer compile.
> 
>   int i = 1;
>   if (i) {}
> 
> This would instead give an error something like "no implicit conversion from int to bool".

if (i) {} does not mean that i is converted to a bool and then tested. It's just a shortcut for if (i != 0) {}.


Andrei

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>>
>> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly.
> 
> 
> Exactly.
> 
>  > Walter is willing to fix D in accordance to that
> 
>> rule, which would yield an implicit conversion graph as shown in:
>>
>> http://erdani.org/d-implicit-conversions.pdf
>>
>> Notice that there is no arrow e.g. between int and uint (loss of meaning), or between int and float (loss of precision). But there is an arrow from int and uint to double, because double is able to represent them faithfully.
>>
>> If we are nice, we may convince Walter to implement that soon (maybe in 1.006?) but it must be understood that the tighter rules will prompt changes in existing code.
> 
> 
> That's fine with me.  Many of us have been asking for this for quite a while.

Yeah, me too. Don't care if it means 1 change or 1,000 in my code ...

Bill Baxter Wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
> 
> > Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
> > 
> > http://erdani.org/d-implicit-conversions.pdf
> > 
> 
> I notice the graph doesn't include complex types.
> Is there any reason why float shouldn't be automatically converted to
> cfloat?
> 
> --bb

Yes.
It used to. It was removed at my request. The problem is, that it introduces *two* directions that float can be converted to.

float -> double -> real
and
float -> cfloat.

Suppose you have:
void func(real) {}
void func(creal){}

and then you type:
func(3.1);

What happens? 3.1 is a double, not a real, so there's no exact match. So the compiler has an ambiguous conversion, and the code won't compile.

Consequence: under the old rules, if you provide both real and complex overloads for a function, you must provide float, double, and real versions.
If the function has multiple arguments, you must provide all combinations. It's untenable.

Note that the same thing happens if you had int-> double conversions:
func(long)
func(real)

--> you must provide func(int) and func(short) variants.

If would be OK if there was a rule that 'lengthening' conversions
char > wchar > dchar, byte > short> int > long, float>double>real, ...
were preferred over meaning-changing conversions
(char > byte, wchar > ushort, int > double, ....)

but that would require another level of matching in the lookup rules.

Andrei Alexandrescu (See Website For Email) wrote:
> Henning Hasemann wrote:
>> I know this is a more general questions as it applies to C and C++ as well,
>> but somewhere I have to ask and actually D is what Im coding in:
>>
>> Should one try to use uint in favor of int whenever one knows for sure the value
>> wont be negative? That whould be a bit more expressive but on the other hand
>> sometimes leads to type problems.
>> For example, when having things like this:
>>
>> T min(T)(T a, T b) {
>>   return a < b ? a : b;
>> }
>>
>> Here you whould need to ensure to cast values so they share a common type.
>>
>> How do you code? Do you use uint whenever it suitable reflects the data to
>> store (eg a x-y-position on the screen) or only when necessary?
> 
> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
> 
> http://erdani.org/d-implicit-conversions.pdf

's got my vote!

L.

don wrote:
> Bill Baxter Wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
>>>
>>> http://erdani.org/d-implicit-conversions.pdf
>>>
>> I notice the graph doesn't include complex types.
>> Is there any reason why float shouldn't be automatically converted to cfloat?
>>
>> --bb
> 
> Yes.
> It used to. It was removed at my request. The problem is, that it introduces *two* directions that float can be converted to.
> 
> float -> double -> real
> and
> float -> cfloat.
> 
> Suppose you have:
> void func(real) {}
> void func(creal){}
> 
> and then you type:
> func(3.1);
> 
> What happens? 3.1 is a double, not a real, so there's no exact match. So the compiler has an ambiguous conversion, and the code won't compile.
> 
> Consequence: under the old rules, if you provide both real and complex overloads for a function, you must provide float, double, and real versions.
> If the function has multiple arguments, you must provide all combinations. It's untenable.

Hmm.  Well maybe in that case there should be a distinction made based on context.  Because to me, this being an error is just silly:
   cfloat x = 1.0;

--bb

Andrei Alexandrescu (See Website For Email) wrote:
> Henning Hasemann wrote:
>> I know this is a more general questions as it applies to C and C++ as well,
>> but somewhere I have to ask and actually D is what Im coding in:
>>
>> Should one try to use uint in favor of int whenever one knows for sure the value
>> wont be negative? That whould be a bit more expressive but on the other hand
>> sometimes leads to type problems.
>> For example, when having things like this:
>>
>> T min(T)(T a, T b) {
>>   return a < b ? a : b;
>> }
>>
>> Here you whould need to ensure to cast values so they share a common type.
>>
>> How do you code? Do you use uint whenever it suitable reflects the data to
>> store (eg a x-y-position on the screen) or only when necessary?
> 
> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
> 
> http://erdani.org/d-implicit-conversions.pdf
> 

By the way, do you think bool should be implicitely convertible to a
numeric type? Such that this preciousness is allowed in D:

  if( true == 2 ) writeln("THEN");

and the "then" clause is not executed.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Henning Hasemann wrote:
>>> I know this is a more general questions as it applies to C and C++ as well,
>>> but somewhere I have to ask and actually D is what Im coding in:
>>>
>>> Should one try to use uint in favor of int whenever one knows for sure the value
>>> wont be negative? That whould be a bit more expressive but on the other hand
>>> sometimes leads to type problems.
>>> For example, when having things like this:
>>>
>>> T min(T)(T a, T b) {
>>>   return a < b ? a : b;
>>> }
>>>
>>> Here you whould need to ensure to cast values so they share a common type.
>>>
>>> How do you code? Do you use uint whenever it suitable reflects the data to
>>> store (eg a x-y-position on the screen) or only when necessary?
>>
>> Current D botches quite a few of the arithmetic conversions. Basically all conversions that may lose value, meaning, or precision should not be allowed implicitly. Walter is willing to fix D in accordance to that rule, which would yield an implicit conversion graph as shown in:
>>
>> http://erdani.org/d-implicit-conversions.pdf
>>
> 
> By the way, do you think bool should be implicitely convertible to a
> numeric type? Such that this preciousness is allowed in D:
> 
>   if( true == 2 ) writeln("THEN");
> 
> and the "then" clause is not executed.

I don't like it. I couldn't convince Walter.

Andrei