Is -1 > 7 ?

[Andre Artus]

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.