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.
