Programming Language for Games, part 3

[Johannes Pfau via Digitalmars-d]

Am Mon, 03 Nov 2014 16:29:17 -0800
schrieb Walter Bright <newshound2 at digitalmars.com>:

> 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.

Although I might agree that warnings can indicate 'wishy-washy language
design' you can not simply assume the reverse/negation. There's
obviously a problem and just 'not adding warnings' doesn't magically
solve this 'wishy-washy language design' issue.
And as long as there is no other solution warnings are better than
simply ignoring the problem.

But I think it's likely this check will be implemented in
Dscanner (https://github.com/Hackerpilot/Dscanner/issues/204) and
in the end it doesn't really matter where it's implemented.