On 7/8/2024 5:37 PM, Timon Gehr wrote:
> Templates are inferred by default:

Thanks for the explanation. It's just @safe templates cannot call @system functions.

Essentially, if you have mixed safe functions and system functions, unannotated, and then you apply Shazaam! Make it all @safe! then yes, you're going to have to deal with the code that cannot safe.

I don't see this as a problem. It's the whole point.

On 7/8/2024 4:18 PM, Timon Gehr wrote:
> The simple fact is that if you program in a language without footguns, you are free to not worry about shooting your own foot. (Assuming you like having feet.)

A "footgun" is just another word for "bug". There is no known way to craft a computer language to make bugs impossible.

Oh, perhaps there is a way - a programming language that doesn't allow you to do anything.

On 7/10/24 23:47, Walter Bright wrote:
> On 7/8/2024 5:37 PM, Timon Gehr wrote:
>> Templates are inferred by default:
> 
> Thanks for the explanation. It's just @safe templates cannot call @system functions.
> ...

No. That's not it. A template that calls a system function is just not `@safe`, and is inferred that way.

The issue is that there is no way to say "@safe by default, keep inference enabled", you can only say "@safe, disable inference".

Therefore, you are either stuck with `@system` by default or you are left with no `@safe` inference.

> Essentially, if you have mixed safe functions and system functions, unannotated, and then you apply Shazaam! Make it all @safe! then yes, you're going to have to deal with the code that cannot safe.
> 
> I don't see this as a problem. It's the whole point.

That's the point of writing `@safe:`. This is however not what is needed in this context.

The problem is not with `@safe:`, it is that there is a missing feature.

On 7/10/24 23:50, Walter Bright wrote:
> On 7/8/2024 4:18 PM, Timon Gehr wrote:
>> The simple fact is that if you program in a language without footguns, you are free to not worry about shooting your own foot. (Assuming you like having feet.)
> 
> A "footgun" is just another word for "bug".

This is not true. A footgun in this context is something that encourages the creation of bugs. A "footgun" is another word for "error-prone design".

> There is no known way to craft a computer language to make bugs impossible.
> 
> Oh, perhaps there is a way - a programming language that doesn't allow you to do anything.

There is a wide spectrum between the two extremes. You are here engaging in unproductive black and white thinking.

Again, just watch your own keynote from last year's DConf. All airplanes can crash, that does not mean all cockpit designs are equivalent.

The missing feature is there:

```
@safe {
   .. templates that must be safe ..
}

.. templates that infer safe ..
```

On 11/07/2024 2:31 PM, Walter Bright wrote:
> The missing feature is there:
> 
> ```
> @safe {
>     .. templates that must be safe ..
> }
> 
> .. templates that infer safe ..
> ```

The point is, once @safe is the default, that capability goes away without @infer.

On 7/10/2024 7:31 PM, Walter Bright wrote:
> The missing feature is there:
> 
> ```
> @safe {
>     .. templates that must be safe ..
> }
> 
> .. templates that infer safe ..
> ```

I might also add that it is good practice to put your unsafe code in another module, as well as code that may be inferred as unsafe.

In any case, we can keep adding more and more features to the language that add very little. But it's not going to go well, and nobody is going to read the 1000 page specification. C and C++ have both gone down that path.

On 7/10/2024 5:19 PM, Timon Gehr wrote:
> On 7/10/24 23:50, Walter Bright wrote:
>> On 7/8/2024 4:18 PM, Timon Gehr wrote:
>>> The simple fact is that if you program in a language without footguns, you are free to not worry about shooting your own foot. (Assuming you like having feet.)
>>
>> A "footgun" is just another word for "bug".
> 
> This is not true. A footgun in this context is something that encourages the creation of bugs. A "footgun" is another word for "error-prone design".

2's complement arithmetic? Floating point arithmetic? Operator precedence?

All of those are footguns. We live with them because attempts to avoid them make for slow and complex code.

Back in the 70's, I read the "Pascal User Manual and Report", and decided to try to write some programs in Pascal. Wirth had removed so many footguns, I could not write a useful program with it. It also just looked ugly. Wirth simply went too far. Subsequent implementations of Pascal had to add a lot of footguns to make it a useful language.


> There is a wide spectrum between the two extremes. You are here engaging in unproductive black and white thinking.

I'm illustrating a point - that moving to "a language without footguns" is not practical. In solving engineering problems, a very productive way of settings up is specifying the boundary conditions. Same here.

May I say you brought it up!


> Again, just watch your own keynote from last year's DConf. All airplanes can crash, that does not mean all cockpit designs are equivalent.

I regularly emphasize "use your best judgement", not blindly following rules. I don't rigidly follow all the rules in my presentation, either.

Not matching C's and C++'s struct layouts by default is a pretty big footgun, and it includes the risk of memory corruption. One also would be less likely to have added tests for it.

Use of bitfields for externally imposed layouts is a frankly unusual case, and having one's layout not match it quite right is rather normal when doing such things. One would expect testing to cover it. It also is not a memory corruption problem. I.e. it's a much smaller footgun.

P.S. What about extern(C) vs extern(D) functions? Is that a footgun? No, because the linker will barf if your code conflates the two. The linker has no information on struct layouts. Neither does a shared library interface.

Iain has complained bitterly in the past, with 100% justification, that we'd change the struct layouts in the D front end and neglect to change the corresponding .h files. The result was always mysterious and difficult to find bugs. The end result was the tool to autogenerate frontend.h and compare it for differences. Do we really want to inflict that on our users by default? Matching the layout is a big deal.

On 7/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:
> The point is, once @safe is the default, that capability goes away without @infer.

I understand that.

First, @system code should be a very small part of a program. If complex things are being done with layers of templates in @system code, I propose that is a badly designed program.

Second, just declare them @trusted until one gets around to a proper refactoring.

In fact, I've been doing just that. Adding @safe: at the top, and then everything that fails to compile gets marked @trusted. Eventually, refactor the code as time permits.

No need for Yet Another Attribute.

On 11/07/2024 5:59 PM, Walter Bright wrote:
> On 7/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:
>> The point is, once @safe is the default, that capability goes away without @infer.
> 
> I understand that.
> 
> First, @system code should be a very small part of a program. If complex things are being done with layers of templates in @system code, I propose that is a badly designed program.
> 
> Second, just declare them @trusted until one gets around to a proper refactoring.
> 
> In fact, I've been doing just that. Adding @safe: at the top, and then everything that fails to compile gets marked @trusted. Eventually, refactor the code as time permits.
> 
> No need for Yet Another Attribute.

Yeah I get that, but that is a major problem for things like std.algorithm.

There will be situations without a migration path forward.