Programming Language for Games, part 3

[H. S. Teoh via Digitalmars-d]

On Mon, Nov 03, 2014 at 04:29:17PM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/3/2014 10:03 AM, Nick Treleaven wrote:
> >On 02/11/2014 20:33, Walter Bright wrote:
> >>It's simply not workable to put a wall between them. Every proposal
> >>for it has entailed various unfortunate, ugly, and arbitrary
> >>consequences.
> >
> >We need warnings like gcc has:
> >
> >"-Wsign-compare
> >     Warn when a comparison between signed and unsigned values could
> >     produce an incorrect result when the signed value is converted
> >     to unsigned.
> >
> >-Wconversion
> >     Warn for implicit conversions that may alter a value. This
> >     includes ... conversions between signed and unsigned, like
> >     unsigned ui = -1 ... Warnings about conversions between signed
> >     and unsigned integers can be disabled by using
> >     -Wno-sign-conversion.
> >"
> 
> I find these to suffer from the same problems as all the proposals to
> "fix" the issue - they motivate the user to "fix" them with
> unfortunate, ugly, and arbitrary consequences.
> 
> We need to be very careful with the idea of "just add a warning".
> Warnings are a sure sign of wishy-washy language design where the
> designers cannot make up their mind, so they dump it on the user. One
> person's warning become another person's must fix, and the language
> becomes balkanized, which is not good for portability,
> comprehensibility, and best practices.
[...]

Don't add a warning, just make it outright illegal to assign signed to
unsigned and vice versa unless an explicit cast is given. Code that
*needs* to assign signed to unsigned *should* be self-documented with a
cast indicating a reinterpretation of the bit representation of the
value, and code that *unintentionally* mixes signs is buggy and
therefore *should* result in a compile error so that the programmer can
fix the problem.

There are no "unfortunate", "ugly", or "arbitrary" consequences here.
Much like the recent (or not-so-recent) change of prohibiting implicit
conversion of a pointer to bool in an if-condition, or the requirement
of a default case in a non-final switch, or so many other improvements
in D over C/C++, such a change will (1) make problematic code an error
so that it will get fixed, and (2) force users to rewrite
non-problematic code to be more self-documenting so that their intent is
clearer. Sounds like a win-win situation to me.


T

-- 
Bomb technician: If I'm running, try to keep up.