On Thursday, 28 May 2020 at 09:33:26 UTC, Walter Bright wrote:
> On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
>>  since he won't listen
>
> More accurately "does not agree".

...and fails to present sound arguments in defense of his position. The problem is not disagreeing.

On 28/05/2020 12:51 PM, Nicholas Wilson wrote:
> 
> Thats a brilliant idea, however the issue of extern still remains with the additional complication of mangling due to attributes and also separate compilation/.di files.

.di files are not an issue.

When the compiler writes them out, just include the attribute with it...

Under such a scheme the compiler may not even know it was inferred.

On Wednesday, 27 May 2020 at 21:01:51 UTC, Steven Schveighoffer wrote:
> On 5/27/20 2:50 PM, Jonathan M Davis wrote:
>
>> [...]
>
> In general, I think @safe, nothrow, @nogc, and pure by default have some benefits on code that is actually compiled by a D compiler. Simply because most of the time, code you write is generally in these categories, but isn't marked as such.
>
> [...]

+1 ....

On Thursday, 28 May 2020 at 09:33:26 UTC, Walter Bright wrote:
> On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
>>  since he won't listen
>
> More accurately "does not agree".

1. D`s @safe is not powerful enough to be used with manual memory management.
2. Because of 1 people dont see enough value in using @safe in their code especially if it interfaces with C libraries.
3. Because of 2 when @safe becomes default, people will use the least effort required way to shut up the compiler. Meaning @safe: at top level of a module.
4. Because of 3 you think compiler should mark extern C functions as safe by default.

Most of the talks in this forum focused on 4. I think people missed the forest for the trees. The real problem is 1. As long as there are no way to mechanically verify use of malloc and free to be safe, or at least wrap in easy to use safe constructs, I dont see any way how DIP 1028 can be changed to not be problematic. As long as @safe is not useful enough all potential outcomes of DIP 1028 are bad.

But I am just random guy on the internet.

On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
> There's no question that there is code that cannot afford the extra cost of exception handling and has to do something else, but it's much more error-prone and isn't the norm for programs in general

I think you misunderstood why some people for example in game engine development are against the use of exceptions. When you have complex system and you have to verify that right things are done trough all possible control flow paths anything that complicates this is frowned upon. What exceptions do is they inflate control flow graph making almost impossible to verify that your system does the right thing in all situations and that would increase bugs in your system

On Thursday, 28 May 2020 at 07:36:05 UTC, Paolo Invernizzi wrote:

> tuning the hot path is still the way to go if you care for speed.

You havent done many optimizations have you? The few hot spots happens when you have a simple program or there were no attempts made to optimize the code. If you profile say DMD code you will find that there are no hot spots. If you want the code to be fast you need to care about all of it. Some parts need more attention than others but you still need to care about it.

On Wednesday, 27 May 2020 at 23:57:00 UTC, Meta wrote:
> What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.

One point of view can be to consider the consequences of fixing code that incorrectly uses the default.

If we have throws-by-default, then marking an existing non-templated method `@nothrow` is not a breaking change.

If we have nothrow-by-default, then marking an existing non-templated method `@throws` is a breaking change.

Another point of view could be that there's a benefit to being permissive by default in terms of what the developer can do.

On Thursday, 28 May 2020 at 13:42:24 UTC, Joseph Rushton Wakeling wrote:
> One point of view can be to consider the consequences of fixing code that incorrectly uses the default.

The beauty of inferred by default is neither are breaking changes.

...and both are breaking changes, but an inferred default is explicitly not guaranteed to remain the same across version updates, so people should be more expecting of it to change.

On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
> The beauty of inferred by default is neither are breaking changes.

Not sure I agree about that TBH.  Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.

On Thursday, 28 May 2020 at 14:53:26 UTC, Joseph Rushton Wakeling wrote:
> On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
>> The beauty of inferred by default is neither are breaking changes.
>
> Not sure I agree about that TBH.  Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.

... which OK, you explicitly did acknowledge, but the point is, this is exactly why I don't like inferred-by-default :-)