On 2021-11-05 10:22, jfondren wrote:
> 3. a compile-time error (also proposed in the thread)

Speaking of which, I was thinking std2x should simply reject mixed-sign min and max during compilation instead of cleverly figuring out the "right" comparison. Now we have signed() and unsigned() that make it trivial for the user to steer min and max toward doing the right thing, and it's clearer too.

On 05.11.21 15:22, jfondren wrote:
> 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)

4. Don't decode. Just do an implicit conversion from char to dchar. Just like `char c; dchar d = c;`. It's horrible, but D usually allows it. So let foreach do it too.

But I'd rather get an error (i.e. #3). And disallow the implicit conversion as well while you're at it.

On 11/5/2021 6:25 AM, Andrei Alexandrescu wrote:
> 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.

All the compilers I know of abandon many optimizations in the presence of unwind blocks.

For example, register allocation of variables is not done across unwind blocks. This is because the unwinder does not restore register contents.

A further problem is data flow analysis becomes largely ineffective because any operation that may throw (such as a function call to a throwing function) produces an edge from there to the catch block.

On 11/5/2021 5:38 AM, max haughton wrote:
> I have never ever seen someone use a static array by mistake, is what I meant,

I didn't mean by mistake. I mean using it as a matter of convenience.

> since you still  want a constant length buffer but want iterators etc..

This is why D has special support for turning arrays seamlessly into ranges. An early goal of D is to encourage use of [ ], rather than deprecate it.

On Friday, 5 November 2021 at 20:41:34 UTC, Walter Bright wrote:
> On 11/5/2021 6:25 AM, Andrei Alexandrescu wrote:
>> 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.
>
> All the compilers I know of abandon many optimizations in the presence of unwind blocks.
>
> For example, register allocation of variables is not done across unwind blocks. This is because the unwinder does not restore register contents.
>
> A further problem is data flow analysis becomes largely ineffective because any operation that may throw (such as a function call to a throwing function) produces an edge from there to the catch block.

I have not checked for GCC, but modern version of LLVM are pretty good at optimizing in the presence of landing pads. Not so good at optimizing the landing pad themselves, but hey, if you get there often, something has gone horribly wrong and optimization is the least of your concerns.

While I have not checked GCC, I'm fairly confident it does a good job.

That being said, on windows, it's another can of worm, because their exception ABI is some special level of crazy.

On Friday, 5 November 2021 at 10:30:27 UTC, Ola Fosheim Grøstad wrote:
> I also think it would be useful to have something stronger than @safe, like a  @non-trojan marker for libraries, which basically says that it is impossible for that library to do evil and have that statically checked by the compiler.

pure

On 11/5/21 5:38 AM, max haughton wrote:

> I have never ever seen someone use a static array by mistake

Related, although safe, vector::at is almost never used because the more convenient (but unsafe) vector.operator[] exists:

  v[42]     // What Ali saw in the wild
  v.at(42)  // What Ali did not see as much in the wild

Ali

On Friday, 5 November 2021 at 22:31:59 UTC, Elronnd wrote:
> On Friday, 5 November 2021 at 10:30:27 UTC, Ola Fosheim Grøstad wrote:
>> I also think it would be useful to have something stronger than @safe, like a  @non-trojan marker for libraries, which basically says that it is impossible for that library to do evil and have that statically checked by the compiler.
>
> pure

Hmm, technically pure code can infinite loop and cause a DOS.  But any useful language will be able to get arbitrary recursion depth even if it is proved to terminate (e.g. cpp), sooo...

And there is also the obvious pitfall of debug-in-pure.

On 11/5/2021 2:43 PM, deadalnix wrote:
> I have not checked for GCC, but modern version of LLVM are pretty good at optimizing in the presence of landing pads.

I saw a presentation by Chandler Carruth at CPPCON 3 years back or so where he said that LLVM abandoned much of the optimizations in the presence of rewind blocks.

Optimizations will do better, of course, if your tight loops don't call functions that might throw.

You'll also lose simply because the extra bulk of the EH code will push more of your hot code out of the cache.

On 2021-11-05 16:41, Walter Bright wrote:
> On 11/5/2021 6:25 AM, Andrei Alexandrescu wrote:
>> 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.
> 
> All the compilers I know of abandon many optimizations in the presence of unwind blocks.
> 
> For example, register allocation of variables is not done across unwind blocks. This is because the unwinder does not restore register contents.
> 
> A further problem is data flow analysis becomes largely ineffective because any operation that may throw (such as a function call to a throwing function) produces an edge from there to the catch block.

I know the story. It is aging. I'm telling the facts. It turns out that modern compilers have made a lot of progress in the area.