On Monday, 3 November 2014 at 21:11:07 UTC, Andrei Alexandrescu
wrote:
> and then meeting for beers. -- Andrei

Be aware that he doesn't drink (alcohol) too much:
https://twitter.com/Jonathan_Blow/status/515268581525700608

Matheus.

On 11/3/2014 12:10 PM, John wrote:
> On Saturday, 1 November 2014 at 20:14:15 UTC, Walter Bright wrote:
>>
>> Jonathan is reinventing D with a somewhat different syntax. Some points on the
>> video:
>
>
> May be you should have a couple of beers with him too, just like you did with
> Andrei a long time ago! :)

I'd like that. Jonathan is quite a likable fellow, and we've been exchanging some nice emails.

On 11/3/14 11:27 PM, MattCoder wrote:
> On Monday, 3 November 2014 at 21:11:07 UTC, Andrei Alexandrescu
> wrote:
>> and then meeting for beers. -- Andrei
>
> Be aware that he doesn't drink (alcohol) too much:
> https://twitter.com/Jonathan_Blow/status/515268581525700608
>
> Matheus.

Thanks. Coffee is even better! -- Andrei

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.

> It is really unfortunate that D is more bug-prone than gcc in this case.

I'm afraid that is a matter of opinion.

> There was some promising work here:
>
> https://github.com/D-Programming-Language/dmd/pull/1913

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.

On 11/3/2014 4:49 PM, H. S. Teoh via Digitalmars-d wrote:
> Don't add a warning, just make it outright illegal to assign signed to
> unsigned and vice versa unless an explicit cast is given.

This has been proposed before.

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

Should be careful with analogies like that. Each case is different. Your proposal (which has been proposed many times before) requires, as you say, explicit casting. You are glossing over and dismissing the problems with explicit casts, and the problems with overloading, etc.

On 2014-11-01 12:31, bearophile wrote:
> Third part of the "A Programming Language for Games", by Jonathan Blow:
> https://www.youtube.com/watch?v=UTqZNujQOlA
>
> Discussions:
> http://www.reddit.com/r/programming/comments/2kxi89/jonathan_blow_a_programming_language_for_games/
>
>
> His language seems to disallow comparisons of different types:
>
> void main() {
>      int x = 10;
>      assert(x == 10.0); // Refused.
> }
>
>
> I like the part about compile-time tests for printf:
> http://youtu.be/UTqZNujQOlA?t=38m6s
>
> The same strategy is used to validate game data statically:
> http://youtu.be/UTqZNujQOlA?t=55m12s
>
> A screenshot for the printf case:
> http://oi57.tinypic.com/2m5b680.jpg
>
> He writes a function that is called to verify at compile-time the
> arguments of another function. This does the same I am asking for a
> "static precondition", but it has some disadvantages and advantages. One
> advantage is that the testing function doesn't need to be in the same
> module as the function, unlike static enums. So you can have the
> function compiled (separated compilation). Perhaps it's time for DIP.

LLVM has a JIT compiler, LDC uses LLVM. Perhaps time to see if it's possible to use the JIT compiler for CTFE.

-- 
/Jacob Carlborg

On Tuesday, 4 November 2014 at 08:26:36 UTC, Jacob Carlborg wrote:
> LLVM has a JIT compiler, LDC uses LLVM. Perhaps time to see if it's possible to use the JIT compiler for CTFE.

Isn't SDC already able to do JIT compilation for CTFE? I swear I've seen Deadalnix mention it before...

On Tuesday, 4 November 2014 at 08:48:13 UTC, Meta wrote:
> On Tuesday, 4 November 2014 at 08:26:36 UTC, Jacob Carlborg wrote:
>> LLVM has a JIT compiler, LDC uses LLVM. Perhaps time to see if it's possible to use the JIT compiler for CTFE.
>
> Isn't SDC already able to do JIT compilation for CTFE? I swear I've seen Deadalnix mention it before...

Yes, SDC use LLVM's JIT capability to do CTFE.

On Tuesday, 4 November 2014 at 00:51:10 UTC, H. S. Teoh via Digitalmars-d wrote:
> 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.
Simply change the comparison to something that always works:

/// Returns negative value if a < b, 0 if they are equal or positive value if a > b.
/// This will always yield a correct result, no matter which integral types are compared.
/// It uses one extra comparison operation if and only if
/// one type is signed and the other unsigned but has bigger max.
/// For comparison with floating point values the buildin
/// operations have no problem, so we don't handle them here.
C opCmp(T, U)(const(T) a, const(U) b) pure @safe @nogc nothrow if(isIntegral!T && isIntegral!U)
{
   alias Signed!CommonType!(T, U) C;
   static if(isSigned!T && isUnsigned!U && T.sizeof <= U.sizeof)
   {
      return (b > cast(U)T.max) ? -1 : cast(C)a - cast(C)b;
   }
   else static if(isUnsigned!T && isSigned!U && T.sizeof >= U.sizeof)
   {
      return (a > cast(T)U.max) ? 1 : cast(C)a - cast(C)b;
   }
   else // both signed or both unsigned or the unsigned type is smaller and can therefore be safely cast to the signed type
   {
      return cast(C)a - cast(C)b;
   }
}