Ary Borenszweig wrote:
> Chris R. Miller wrote:
>> downs wrote:
>>> Chris R. Miller wrote:
>>>> downs wrote:
>>>>> Jarrett Billingsley wrote:
>>>>>> On Wed, Sep 17, 2008 at 10:26 PM, downs <default_357-line@yahoo.de>
>>>>>> wrote:
>>>>>>> void main() { int i; short x; x = i; }
>>>>>>>
>>>>>>> Excuse me, but - how exactly is it that this is in any way, shape or
>>>>>>> form valid code?
>>>>>>>
>>>>>>> How can I trust a language that allows those kind of shenanigans?
>>>>>>>
>>>>>> lern2warningsflag.
>>>>> "Warning. Your code is broken."
>>>>>
>>>>> I still claim it should actually be an error, although the only
>>>>> practical and correct solution might be full ranged type support.
>>>> I don't get it.  Why can that not be simple implicit type casting?
>>>
>>> Because short is not a superset of int.
>>
>> Well.... then it's just a loss of precision warning like on every other language (Java and C++ off the top of my head).
>>
>> -w and be on thy way, unless I'm missing something else.
> 
> No, no. In Java it's an error, an explicit cast is required.
> 
> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
> 
> Which is perfect. It expresses the intents of the programmer:
> 
> long x = ...;
> int y = (int) x; // yes, I know I might loose information, but I'm sure
>                  // it won't happen
> 
> However, if you see this code (in D):
> 
> long x = ...;
> int y = x;
> 
> you start wondering whether the original author simply forgot to add the cast or he knew what he was doing. How can you know?
> 
> I like the compiler to force you to write an explicit cast. It is saying: "Hey, please tell me you know what you are doing here... because maybe you didn't notice you might loose information here".

Doesn't all this come down to convincing Walter to lose the "must follow C rules" mantra? I doubt that's gonna happen ...

Who knows :)

- Tomas

Tomas Lindquist Olsen wrote:
> Ary Borenszweig wrote:
>> Chris R. Miller wrote:
>>> downs wrote:
>>>> Chris R. Miller wrote:
>>>>> downs wrote:
>>>>>> Jarrett Billingsley wrote:
>>>>>>> On Wed, Sep 17, 2008 at 10:26 PM, downs <default_357-line@yahoo.de>
>>>>>>> wrote:
>>>>>>>> void main() { int i; short x; x = i; }
>>>>>>>>
>>>>>>>> Excuse me, but - how exactly is it that this is in any way, shape or
>>>>>>>> form valid code?
>>>>>>>>
>>>>>>>> How can I trust a language that allows those kind of shenanigans?
>>>>>>>>
>>>>>>> lern2warningsflag.
>>>>>> "Warning. Your code is broken."
>>>>>>
>>>>>> I still claim it should actually be an error, although the only
>>>>>> practical and correct solution might be full ranged type support.
>>>>> I don't get it.  Why can that not be simple implicit type casting?
>>>>
>>>> Because short is not a superset of int.
>>>
>>> Well.... then it's just a loss of precision warning like on every other language (Java and C++ off the top of my head).
>>>
>>> -w and be on thy way, unless I'm missing something else.
>>
>> No, no. In Java it's an error, an explicit cast is required.
>>
>> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
>>
>> Which is perfect. It expresses the intents of the programmer:
>>
>> long x = ...;
>> int y = (int) x; // yes, I know I might loose information, but I'm sure
>>                  // it won't happen
>>
>> However, if you see this code (in D):
>>
>> long x = ...;
>> int y = x;
>>
>> you start wondering whether the original author simply forgot to add the cast or he knew what he was doing. How can you know?
>>
>> I like the compiler to force you to write an explicit cast. It is saying: "Hey, please tell me you know what you are doing here... because maybe you didn't notice you might loose information here".
> 
> Doesn't all this come down to convincing Walter to lose the "must follow C rules" mantra? I doubt that's gonna happen ...

Yeah, when pigs fly, correct?

<looks out window>

Never mind, gotta find a different metaphor.  Stupid viking catapult...  ;-)

On Fri, Sep 19, 2008 at 4:05 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> Chris R. Miller wrote:
> No, no. In Java it's an error, an explicit cast is required.
>
> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
>
> Which is perfect. It expresses the intents of the programmer:
>
> long x = ...;
> int y = (int) x; // yes, I know I might loose information, but I'm sure
>                 // it won't happen
>

Well, I wouldn't say it *perfectly* expresses the programmer's intent.
 I doubt the programmer really intended to say "I want to pretend x is
an int no mater what its actual type is".

By which I mean to say a better expression of the user's intent would be "I want to convert x into an integer so long as it is a type for which the compiler knows how to convert".  I.e. I don't want to accidentally try to convert an array or something like that to an int.

Or maybe that's not an issue in Java?  Maybe it doesn't let you cast arbitrary things to ints.  But anyway D's cast is not like that, so the same solution needs tweaking to port to D.  Like some kind of conversion cast that's distinct from the generic coercive cast.  I suppose that's basically what the modules like std.conv aim to provide.  An alternate kind of cast.  to!(int)(x) instead of cast(int)x.

--bb

Ary Borenszweig:
> No, no. In Java it's an error, an explicit cast is required. http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting Which is perfect. It expresses the intents of the programmer:

About such matters I suggest you all to also take a look at how Ada works. Ada was designed first of all to create reliable software, so avoiding casting-derived bugs too is essential.
D tries to avoid some of the pitfalls of C, to be a language less bug-prone: casts is where D has to improve still in such regards. Time ago (when I was more a D newbie) I have already had a bug in my code because of a casting bug:

import std.stdio;
void main() {
    int n = -5;
    int[] a = [1, 2, 3];
    writefln(a.length > n); // prints false
}

A well designed language, even a system language like Ada or D, must avoid such kinds of bugs, regardless the amount of ignorance of the programmer.

Bye,
bearophile

bearophile wrote:
> Ary Borenszweig:
>> No, no. In Java it's an error, an explicit cast is required.
>> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
>> Which is perfect. It expresses the intents of the programmer:
> 
> About such matters I suggest you all to also take a look at how Ada works. Ada was designed first of all to create reliable software, so avoiding casting-derived bugs too is essential.
> D tries to avoid some of the pitfalls of C, to be a language less bug-prone: casts is where D has to improve still in such regards. Time ago (when I was more a D newbie) I have already had a bug in my code because of a casting bug:
> 
> import std.stdio;
> void main() {
>     int n = -5;
>     int[] a = [1, 2, 3];
>     writefln(a.length > n); // prints false
> }
> 
> A well designed language, even a system language like Ada or D, must avoid such kinds of bugs, regardless the amount of ignorance of the programmer.

Wow. At first, I thought that was already fixed. Now I've written that code, compiled it and run it and saw it gives false. Ok, I know a.length is an uint because logically it cannot be negative. But... shouldn't it be an int to avoid this kind of bugs?? You loose nothing doing this. You are never going to need an array of 2147483647 positions, much less a bigger array.

I've checked C#, which has uint as a type. The length of an array is an int, not an unit. A much better choice.

> Bye,
> bearophile

On Fri, Sep 19, 2008 at 9:29 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> bearophile wrote:
>>
>> Ary Borenszweig:
>>>
>>> No, no. In Java it's an error, an explicit cast is required. http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting Which is perfect. It expresses the intents of the programmer:
>>
>> About such matters I suggest you all to also take a look at how Ada works.
>> Ada was designed first of all to create reliable software, so avoiding
>> casting-derived bugs too is essential.
>> D tries to avoid some of the pitfalls of C, to be a language less
>> bug-prone: casts is where D has to improve still in such regards. Time ago
>> (when I was more a D newbie) I have already had a bug in my code because of
>> a casting bug:
>>
>> import std.stdio;
>> void main() {
>>    int n = -5;
>>    int[] a = [1, 2, 3];
>>    writefln(a.length > n); // prints false
>> }
>>
>> A well designed language, even a system language like Ada or D, must avoid such kinds of bugs, regardless the amount of ignorance of the programmer.
>
> Wow. At first, I thought that was already fixed. Now I've written that code, compiled it and run it and saw it gives false. Ok, I know a.length is an uint because logically it cannot be negative. But... shouldn't it be an int to avoid this kind of bugs?? You loose nothing doing this. You are never going to need an array of 2147483647 positions, much less a bigger array.
>
> I've checked C#, which has uint as a type. The length of an array is an int, not an unit. A much better choice.

signed-unsigned comparison is, I think, a slightly larger problem than the type of array.length ;)

Jarrett Billingsley wrote:
> On Fri, Sep 19, 2008 at 9:29 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>> bearophile wrote:
>>> Ary Borenszweig:
>>>> No, no. In Java it's an error, an explicit cast is required.
>>>> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
>>>> Which is perfect. It expresses the intents of the programmer:
>>> About such matters I suggest you all to also take a look at how Ada works.
>>> Ada was designed first of all to create reliable software, so avoiding
>>> casting-derived bugs too is essential.
>>> D tries to avoid some of the pitfalls of C, to be a language less
>>> bug-prone: casts is where D has to improve still in such regards. Time ago
>>> (when I was more a D newbie) I have already had a bug in my code because of
>>> a casting bug:
>>>
>>> import std.stdio;
>>> void main() {
>>>    int n = -5;
>>>    int[] a = [1, 2, 3];
>>>    writefln(a.length > n); // prints false
>>> }
>>>
>>> A well designed language, even a system language like Ada or D, must avoid
>>> such kinds of bugs, regardless the amount of ignorance of the programmer.
>> Wow. At first, I thought that was already fixed. Now I've written that code,
>> compiled it and run it and saw it gives false. Ok, I know a.length is an
>> uint because logically it cannot be negative. But... shouldn't it be an int
>> to avoid this kind of bugs?? You loose nothing doing this. You are never
>> going to need an array of 2147483647 positions, much less a bigger array.
>>
>> I've checked C#, which has uint as a type. The length of an array is an int,
>> not an unit. A much better choice.
> 
> signed-unsigned comparison is, I think, a slightly larger problem than
> the type of array.length ;)

But if the length of an array is an uint, if you compare it to an int then what bearophile has just shown might happen.

Now, if the length of an array is an int, but which is guaranteed to be always positive or zero, then if you compare it to an int or an unit, you always get the desired result.

Conclusion: you avoid a bug to happen at zero cost.

So... why not?

On Fri, Sep 19, 2008 at 9:45 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> Jarrett Billingsley wrote:
>>
>> On Fri, Sep 19, 2008 at 9:29 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>>
>>> bearophile wrote:
>>>>
>>>> Ary Borenszweig:
>>>>>
>>>>> No, no. In Java it's an error, an explicit cast is required. http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting Which is perfect. It expresses the intents of the programmer:
>>>>
>>>> About such matters I suggest you all to also take a look at how Ada
>>>> works.
>>>> Ada was designed first of all to create reliable software, so avoiding
>>>> casting-derived bugs too is essential.
>>>> D tries to avoid some of the pitfalls of C, to be a language less
>>>> bug-prone: casts is where D has to improve still in such regards. Time
>>>> ago
>>>> (when I was more a D newbie) I have already had a bug in my code because
>>>> of
>>>> a casting bug:
>>>>
>>>> import std.stdio;
>>>> void main() {
>>>>   int n = -5;
>>>>   int[] a = [1, 2, 3];
>>>>   writefln(a.length > n); // prints false
>>>> }
>>>>
>>>> A well designed language, even a system language like Ada or D, must
>>>> avoid
>>>> such kinds of bugs, regardless the amount of ignorance of the
>>>> programmer.
>>>
>>> Wow. At first, I thought that was already fixed. Now I've written that
>>> code,
>>> compiled it and run it and saw it gives false. Ok, I know a.length is an
>>> uint because logically it cannot be negative. But... shouldn't it be an
>>> int
>>> to avoid this kind of bugs?? You loose nothing doing this. You are never
>>> going to need an array of 2147483647 positions, much less a bigger array.
>>>
>>> I've checked C#, which has uint as a type. The length of an array is an
>>> int,
>>> not an unit. A much better choice.
>>
>> signed-unsigned comparison is, I think, a slightly larger problem than the type of array.length ;)
>
> But if the length of an array is an uint, if you compare it to an int then what bearophile has just shown might happen.
>
> Now, if the length of an array is an int, but which is guaranteed to be always positive or zero, then if you compare it to an int or an unit, you always get the desired result.
>
> Conclusion: you avoid a bug to happen at zero cost.
>
> So... why not?
>

The point is that signed-unsigned comparison _in general_ is a bad thing, and array.length-int is just one manifestation of it.  If signed-unsigned comparison were made illegal, this would be an error.

Jarrett Billingsley wrote:
> On Fri, Sep 19, 2008 at 9:45 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>> Jarrett Billingsley wrote:
>>> On Fri, Sep 19, 2008 at 9:29 AM, Ary Borenszweig <ary@esperanto.org.ar>
>>> wrote:
>>>> bearophile wrote:
>>>>> Ary Borenszweig:
>>>>>> No, no. In Java it's an error, an explicit cast is required.
>>>>>> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
>>>>>> Which is perfect. It expresses the intents of the programmer:
>>>>> About such matters I suggest you all to also take a look at how Ada
>>>>> works.
>>>>> Ada was designed first of all to create reliable software, so avoiding
>>>>> casting-derived bugs too is essential.
>>>>> D tries to avoid some of the pitfalls of C, to be a language less
>>>>> bug-prone: casts is where D has to improve still in such regards. Time
>>>>> ago
>>>>> (when I was more a D newbie) I have already had a bug in my code because
>>>>> of
>>>>> a casting bug:
>>>>>
>>>>> import std.stdio;
>>>>> void main() {
>>>>>   int n = -5;
>>>>>   int[] a = [1, 2, 3];
>>>>>   writefln(a.length > n); // prints false
>>>>> }
>>>>>
>>>>> A well designed language, even a system language like Ada or D, must
>>>>> avoid
>>>>> such kinds of bugs, regardless the amount of ignorance of the
>>>>> programmer.
>>>> Wow. At first, I thought that was already fixed. Now I've written that
>>>> code,
>>>> compiled it and run it and saw it gives false. Ok, I know a.length is an
>>>> uint because logically it cannot be negative. But... shouldn't it be an
>>>> int
>>>> to avoid this kind of bugs?? You loose nothing doing this. You are never
>>>> going to need an array of 2147483647 positions, much less a bigger array.
>>>>
>>>> I've checked C#, which has uint as a type. The length of an array is an
>>>> int,
>>>> not an unit. A much better choice.
>>> signed-unsigned comparison is, I think, a slightly larger problem than
>>> the type of array.length ;)
>> But if the length of an array is an uint, if you compare it to an int then
>> what bearophile has just shown might happen.
>>
>> Now, if the length of an array is an int, but which is guaranteed to be
>> always positive or zero, then if you compare it to an int or an unit, you
>> always get the desired result.
>>
>> Conclusion: you avoid a bug to happen at zero cost.
>>
>> So... why not?
>>
> 
> The point is that signed-unsigned comparison _in general_ is a bad
> thing, and array.length-int is just one manifestation of it.  If
> signed-unsigned comparison were made illegal, this would be an error.

Now I see what you mean, and I agree.

Jarrett Billingsley wrote:
> On Fri, Sep 19, 2008 at 9:45 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>> Jarrett Billingsley wrote:
>>> On Fri, Sep 19, 2008 at 9:29 AM, Ary Borenszweig <ary@esperanto.org.ar>
>>> wrote:
>>>> bearophile wrote:
>>>>> Ary Borenszweig:
>>>>>> No, no. In Java it's an error, an explicit cast is required.
>>>>>> http://www.programmersheaven.com/2/FAQ-JAVA-Type-Conversion-Casting
>>>>>> Which is perfect. It expresses the intents of the programmer:
>>>>> About such matters I suggest you all to also take a look at how Ada
>>>>> works.
>>>>> Ada was designed first of all to create reliable software, so avoiding
>>>>> casting-derived bugs too is essential.
>>>>> D tries to avoid some of the pitfalls of C, to be a language less
>>>>> bug-prone: casts is where D has to improve still in such regards. Time
>>>>> ago
>>>>> (when I was more a D newbie) I have already had a bug in my code because
>>>>> of
>>>>> a casting bug:
>>>>>
>>>>> import std.stdio;
>>>>> void main() {
>>>>>   int n = -5;
>>>>>   int[] a = [1, 2, 3];
>>>>>   writefln(a.length > n); // prints false
>>>>> }
>>>>>
>>>>> A well designed language, even a system language like Ada or D, must
>>>>> avoid
>>>>> such kinds of bugs, regardless the amount of ignorance of the
>>>>> programmer.
>>>> Wow. At first, I thought that was already fixed. Now I've written that
>>>> code,
>>>> compiled it and run it and saw it gives false. Ok, I know a.length is an
>>>> uint because logically it cannot be negative. But... shouldn't it be an
>>>> int
>>>> to avoid this kind of bugs?? You loose nothing doing this. You are never
>>>> going to need an array of 2147483647 positions, much less a bigger array.
>>>>
>>>> I've checked C#, which has uint as a type. The length of an array is an
>>>> int,
>>>> not an unit. A much better choice.
>>> signed-unsigned comparison is, I think, a slightly larger problem than
>>> the type of array.length ;)
>> But if the length of an array is an uint, if you compare it to an int then
>> what bearophile has just shown might happen.
>>
>> Now, if the length of an array is an int, but which is guaranteed to be
>> always positive or zero, then if you compare it to an int or an unit, you
>> always get the desired result.
>>
>> Conclusion: you avoid a bug to happen at zero cost.
>>
>> So... why not?
>>
> 
> The point is that signed-unsigned comparison _in general_ is a bad
> thing, and array.length-int is just one manifestation of it.  If
> signed-unsigned comparison were made illegal, this would be an error.

But the solution is NOT to leave the language as-is, only disallowing signed-unsigned comparison. That's a cure that's as bad as the disease.

One of the biggest stupidities from C is that 0 is an int. Once you've done that, you HAVE to have implicit conversions. And once you have implicit conversions, you have to allow signed-unsigned comparision.