D not considered memory safe

[Walter Bright]

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.