On 8/14/13 2:26 PM, Andre Artus wrote:
> On Sunday, 11 August 2013 at 17:01:46 UTC, Yota wrote:
>> On Friday, 9 August 2013 at 17:35:18 UTC, monarch_dodra wrote:
>>> On Friday, 9 August 2013 at 15:28:10 UTC, Manfred Nowak wrote:
>>>> michaelc37 wrote:
>>>>> WTF -> -1 is greater than 7 ????
>>>>
>>>> From the docs:
>>>>
>>>> It is an error to have one operand be signed and the other unsigned
>>>> for a
>>>> <, <=, > or >= expression.
>>>>
>>>> -manfred
>>>
>>> Interesting. I didn't know it was documented as being an outright
>>> error, I thought it was just "surprising"...
>>>
>>> I don't think Walter will ever accept to make it illegal though,
>>> breaks too much code. If this was a change he was OK with, I think we
>>> would have had it since day one, or at least, years ago.
>>
>> I remember hearing somewhere that D is about enforcing users to write
>> CORRECT code.  I would really be disappointed with the language if
>> this sort of gotcha weren't eliminated.
>>
>> If I look at this assert, I shouldn't be expecting it to pass.
>> static assert(-1 > cast(size_t)7);
>>
>> IMHO, as long as this sort of comparison causes a compile-time error,
>> as the docs say they should, this kind of breaking change is the of
>> very good sort.  The sort that reveals bugs in code. (Like when they
>> changed the NULL macro to mean 'nullptr' instead of 0 in C++.) I
>> couldn't imagine a programmer exploiting this intentionally, as it
>> serves no purpose.
>
> I agree, breaking changes that expose bugs in your code are the good
> kind. The time spent fixing compile time errors is more than compensated
> for by the time saved not having to hunt down those bugs.
>
> Having worked with languages where reference types are non-nullable by
> default I wish more languages did the same.

Which are those languages? I'm interested.

On 9.8.2013. 17:11, michaelc37 wrote:
> forgive me if i'm doing something stupid, i'm extremely tired and trying
> to avoid drinking coffee.
>
> void main()
> {
> int[] arr = [0, 1, 2, 3, 4, 5, 6];
>
> //check 1
> if (-1 > arr.length)
> writefln("WTF -> %d is greater than %d ????", -1, arr.length);
> else
> writefln("GOOD -> %d is NOT greater than %d", -1, arr.length);
> }
>
> here is my output:
> WTF -> -1 is greater than 7 ????

http://forum.dlang.org/thread/kn3f9v$25pd$1@digitalmars.com

On Wednesday, 14 August 2013 at 18:08:56 UTC, Ary Borenszweig wrote:
> On 8/14/13 2:26 PM, Andre Artus wrote:
>> On Sunday, 11 August 2013 at 17:01:46 UTC, Yota wrote:
>>> On Friday, 9 August 2013 at 17:35:18 UTC, monarch_dodra wrote:
>>>> On Friday, 9 August 2013 at 15:28:10 UTC, Manfred Nowak wrote:
>>>>> michaelc37 wrote:
>>>>>> WTF -> -1 is greater than 7 ????
>>>>>
>>>>> From the docs:
>>>>>
>>>>> It is an error to have one operand be signed and the other unsigned
>>>>> for a
>>>>> <, <=, > or >= expression.
>>>>>
>>>>> -manfred
>>>>
>>>> Interesting. I didn't know it was documented as being an outright
>>>> error, I thought it was just "surprising"...
>>>>
>>>> I don't think Walter will ever accept to make it illegal though,
>>>> breaks too much code. If this was a change he was OK with, I think we
>>>> would have had it since day one, or at least, years ago.
>>>
>>> I remember hearing somewhere that D is about enforcing users to write
>>> CORRECT code.  I would really be disappointed with the language if
>>> this sort of gotcha weren't eliminated.
>>>
>>> If I look at this assert, I shouldn't be expecting it to pass.
>>> static assert(-1 > cast(size_t)7);
>>>
>>> IMHO, as long as this sort of comparison causes a compile-time error,
>>> as the docs say they should, this kind of breaking change is the of
>>> very good sort.  The sort that reveals bugs in code. (Like when they
>>> changed the NULL macro to mean 'nullptr' instead of 0 in C++.) I
>>> couldn't imagine a programmer exploiting this intentionally, as it
>>> serves no purpose.
>>
>> I agree, breaking changes that expose bugs in your code are the good
>> kind. The time spent fixing compile time errors is more than compensated
>> for by the time saved not having to hunt down those bugs.
>>
>> Having worked with languages where reference types are non-nullable by
>> default I wish more languages did the same.
>
> Which are those languages? I'm interested.

Haskell, there are functions called "null", but they are [normally] equivalent to "isEmpty". Tri-values and other cases for null covered by "Maybe"/"Either".

F#, has null to interface with other .NET languages, but only used on the boundaries. Most other cases for null covered with "option".

Spec#, when compiling with the "/nn" switch. It's a research clone of C# with Eiffel-like features (i.e. contracts). You can cast from a nullable type to a not-null type in which case the compiler inserts a run-time check. There is also a strict type annotation "!" forcing not-null semantics even when compiling without "/nn". Unfortunately it's not being actively maintained (AFAIK) and has fallen behind on the latest C# features. http://specsharp.codeplex.com/

I have not used Eiffel, something about the syntax does not appeal to me [1], but I believe it has the concept of "void safety" which you can read about here:
http://docs.eiffel.com/book/papers/void-safety-how-eiffel-removes-null-pointer-dereferencing


1. I'm not knocking Eiffel, it has pioneered or promoted many important innovations in OOP. My view on the syntax is like my taste in ice-cream: merely a personal opinion.