November 05, 2021
On Friday, 5 November 2021 at 12:03:24 UTC, Ola Fosheim Grøstad wrote:
> For instance in raytracing I would want NaNs. Then I can make a choice based on neighbouring pixels whether I want to compute it again using a slower method or simply fill it in with the average of the neighbours (if all the neighbours have roughly the same colour).

I can't imagine wanting nans in raytracing. Just the idea of a fpu slowpath-provoking nan making its way into my nice wide SSE vectors gives me hives. Any sensible raytracing routine should just never produce a nan to begin with.

(For denormals there's FTZ/DAZ, at least.)
November 05, 2021
On Friday, 5 November 2021 at 06:15:44 UTC, Walter Bright wrote:
> On 11/4/2021 9:11 PM, max haughton wrote:
>> On Friday, 5 November 2021 at 04:02:44 UTC, Walter Bright wrote:
>>> On 11/4/2021 7:41 PM, Mathias LANG wrote:
>>>> If you want to fix it, just deprecate the special case and tell people to use `foreach (dchar d; someString.byUTF!(dchar, No.useReplacementDchar))` and voilà.
>>>> And if they don't want it to throw, it's shorter:
>>>> `foreach (dchar d; someString.byUTF!dchar)` (or `byDChar`).
>>>
>>> People will always gravitate towards the smaller, simpler syntax. Like [] instead of std::vector<>.
>> 
>> I have never observed this mistake in any C++ cod,
>
> You've never observed people write:
>
>    int array[3];
>
> in C++ code?
>
>> unless you mean as a point of language design.
>
> D (still) has a rather verbose way of doing lambdas. People constantly complained that D didn't have lambdas. Until the => syntax was added, and suddenly lambdas in D became noticed and useful.
>
>
>> This decision should be guided by how current D programmers act rather than a hyperreal ideal of someone encountering the language.
>
> The only reason D's associative arrays continue to exist is because they are so darned syntactically convenient.
>
> I've seen over and over and over that syntactic convenience matters a lot.

I have never ever seen someone use a static array by mistake, is what I meant, vector doesn't do the same thing as []. It's more common in (so-called) modern C++ to see std::array these days than a raw static array in certain contexts since you still  want a constant length buffer but want iterators etc..
November 05, 2021
> (This is floating point NaN all over again!)

Did you try Pony language? its so user friendly, it even allows divide by zero.

https://www.reddit.com/r/programming/comments/7al9s2/pony_a_programming_language_that_allows_dividing/




November 05, 2021
On Friday, 5 November 2021 at 12:13:17 UTC, FeepingCreature wrote:
> (For denormals there's FTZ/DAZ, at least.)

Not IEEE?


November 05, 2021
On 2021-11-04 20:40, Walter Bright wrote:
> On 11/4/2021 12:51 AM, Elronnd wrote:
>> In the hot path it's the same speed.
> 
> C++ sold everyone the myth that exceptions not thrown are zero cost. This has been thoroughly debunked, though the myth persists :-(

I've been doing a fair amount of benchmarking for https://amazon.com/Embracing-Modern-Safely-John-Lakos/dp/0137380356 and surprisingly enough the myth holds true in most cases.
November 05, 2021
On 2021-11-04 23:02, deadalnix wrote:
> On Friday, 5 November 2021 at 02:38:51 UTC, Adam D Ruppe wrote:
>> On Friday, 5 November 2021 at 02:06:01 UTC, deadalnix wrote:
>>> On Thursday, 4 November 2021 at 02:26:20 UTC, Walter Bright wrote:
>>>> https://issues.dlang.org/show_bug.cgi?id=22473
>>>
>>> For the love of god, if you are going to make a breaking change there, just remove autodecoding altogether.
>>
>> This post isn't about autodecoding. With foreach, you opt into the decoding by specifically asking for it.
> 
> Very clearly it is, because if you don't decode, then you don't do replacement chars or exceptions.

"On demand" is not "auto".
November 05, 2021
On Friday, 5 November 2021 at 13:25:06 UTC, Andrei Alexandrescu wrote:
> On 2021-11-04 20:40, Walter Bright wrote:
>> On 11/4/2021 12:51 AM, Elronnd wrote:
>>> In the hot path it's the same speed.
>> 
>> C++ sold everyone the myth that exceptions not thrown are zero cost. This has been thoroughly debunked, though the myth persists :-(
>
> I've been doing a fair amount of benchmarking for https://amazon.com/Embracing-Modern-Safely-John-Lakos/dp/0137380356 and surprisingly enough the myth holds true in most cases.

It really depends on the exact specification of the myth.

You get executable bigger by about 20%, and some constructs such as ref counted smart pointer become harder to optimize, but indeed, the cost when you don't throw in term of runtime isn't remotely as high as people seems to think.
November 05, 2021
On Friday, 5 November 2021 at 13:26:00 UTC, Andrei Alexandrescu wrote:
> "On demand" is not "auto".

From the bug repport:

> A simple foreach loop:
> 
>     void test(char[] a)
>     {
>         foreach (char c; a) { }
>     }
> 
> will throw a UtfException if `a` is not a valid UTF string. Instead, it should replace the invalid sequence with replacementDchar.

This shouldn't do anything related to unicode at all.
November 05, 2021
On Friday, 5 November 2021 at 14:10:35 UTC, deadalnix wrote:
> This shouldn't do anything related to unicode at all.

Well, it doesn't. That was apparently just a typo, as the comments in the bug report quickly pointed out, as the thing is when you specifically request dchar out of char, NOT when you are just working on chars (which is the default).
November 05, 2021

On Friday, 5 November 2021 at 14:10:35 UTC, deadalnix wrote:

>

On Friday, 5 November 2021 at 13:26:00 UTC, Andrei Alexandrescu wrote:

>

"On demand" is not "auto".

From the bug repport:

>

A simple foreach loop:

void test(char[] a)
{
    foreach (char c; a) { }
}

will throw a UtfException if a is not a valid UTF string. Instead, it should replace the invalid sequence with replacementDchar.

This shouldn't do anything related to unicode at all.

It doesn't. This does:

unittest {
    enum invalid = "hello\247\205\257there";
    foreach (dchar c; invalid) { }
}

Looping over the dchar of a char[] requires one of

  1. throwing an error on invalid UTF (current behavior)
  2. doing something else in that case (proposed: replacementDchar; also possible: silently doing something invalid like iterating over three dchars between "hello" and "there")
  3. a compile-time error (also proposed in the thread)