On Thursday, 12 May 2016 at 09:22:02 UTC, Nordlöw wrote:
>>> "Comparison is always false: literal 1000 is not representable
>>> as 'byte'"
>
> What's wrong with having this warning?

This is, IMO, just a more informative diagnostic than:

"Statement at `foo()` is not reachable":

in the following code:

    if (b == 1000)
    {
        foo();
    }

On 12 May 2016 at 17:32, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/11/2016 2:24 AM, Manu via Digitalmars-d wrote:
>
>> The reason I'm wary about emitting a warning is because people will
>> encounter the warning *all the time*, and for a user who doesn't have
>> comprehensive understanding of floating point (and probably many that
>> do), the natural/intuitive thing to do would be to place an explicit
>> cast of the lower precision value to the higher precision type, which
>> is __exactly the wrong thing to do__.
>> I don't think the warning improves the problem, it likely just causes
>> people to emit the same incorrect code explicitly.
>
>
> The warning is intended for people who understand, as then they will figure out what they actually wanted and implement that. People who randomly and without comprehension insert casts hoping to make the compiler shut up cannot be helped.

But they can easily be helped by implementing behaviour that makes sense. If you're set on a warning, at least make the warning recommend down-casting the higher precision term to the lower precision?

On 5/12/16 3:32 AM, Walter Bright wrote:
> On 5/11/2016 2:24 AM, Manu via Digitalmars-d wrote:
>> What is the problem with this behaviour I suggest?
>
> Code will do one thing in C, and the same code will do something
> unexpectedly different in D.

Not taking one side or another on this, but due to D doing everything with reals, this is already the case.

-Steve

On Thursday, 12 May 2016 at 13:03:58 UTC, Steven Schveighoffer wrote:
> Not taking one side or another on this, but due to D doing everything with reals, this is already the case.

Mmmm. I don't want to open up another can of worms right now, but our x64 C++ code only emits SSE instructions at compile time (or AVX on the Xbox One). The only thing that attempts to use reals in our codebase is our D code.

On 5/12/16 10:05 AM, Ethan Watson wrote:
> On Thursday, 12 May 2016 at 13:03:58 UTC, Steven Schveighoffer wrote:
>> Not taking one side or another on this, but due to D doing everything
>> with reals, this is already the case.
>
> Mmmm. I don't want to open up another can of worms right now, but our
> x64 C++ code only emits SSE instructions at compile time (or AVX on the
> Xbox One). The only thing that attempts to use reals in our codebase is
> our D code.

There was a question on the forums a while back about equivalent C++ code that didn't work in D. The answer turned out to be, you had to shoehorn everything into doubles in order to get the same answer.

-Steve

On Thursday, 12 May 2016 at 14:29:01 UTC, Steven Schveighoffer wrote:
> There was a question on the forums a while back about equivalent C++ code that didn't work in D. The answer turned out to be, you had to shoehorn everything into doubles in order to get the same answer.

I can certainly see that being the case, especially when dealing with SSE-based code. floats and doubles in XMM registers don't get calculated at 80-bit precision internally, their storage size dictates their calculation precision. Which has led MSVC to promoting floats to doubles for CRT functions when it thinks it can get away with it (and one instance where the compiler forgot to convert back to float afterwards and thus the lower 32 bits of a double were being treated as a float...)

It's fun comparing assembly too. There's one particular function we have here that collapsed to something like 20-30 lines of SSE-based code (half after I hand optimised it with branchless SSE intrinsics and without a call to fmod). The same function in D resulted in a significantly larger amount of x87 code.

I don't miss x87 at all. But this is getting OT.

On 5/12/2016 3:30 AM, Manu via Digitalmars-d wrote:
> But they can easily be helped by implementing behaviour that makes sense.

One thing that's immutably true about computer floating point is that it does not make intuitive sense if your intuition is based on mathematics. It's a hopeless cause trying to bash it into 'making sense'. It's something one has to simply take the time and learn.

This reminds me of all the discussions around trying to hide the fact that D strings are UTF-8 code units. The ultimate outcome of trying to make it "make sense" was the utter disaster of autodecoding.


> If you're set on a warning, at least make the warning recommend
> down-casting the higher precision term to the lower precision?

Yes, of course. I believe error messages should suggest corrective action.

On 5/12/2016 6:03 AM, Steven Schveighoffer wrote:
> Not taking one side or another on this, but due to D doing everything with
> reals, this is already the case.

Actually, C allows that behavior if I understood the spec correctly. D just makes things more explicit.

On Thursday, 12 May 2016 at 15:55:52 UTC, Walter Bright wrote:
> This reminds me of all the discussions around trying to hide the fact that D strings are UTF-8 code units. The ultimate outcome of trying to make it "make sense" was the utter disaster of autodecoding.

Well maybe it was a disaster because the problem was only half solved.
It looks like Perl 6 got it right:
https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/

On 5/12/2016 9:15 AM, Guillaume Chatelet wrote:
> Well maybe it was a disaster because the problem was only half solved.
> It looks like Perl 6 got it right:
> https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/

Perl isn't a systems programming language. A systems language requires access to code units, invalid encodings, etc. Nor is Perl efficient. There are a lot of major efficiency gains by not autodecoding.