DIP 1028--Make @safe the Default--Formal Assessment

[Walter Bright]

On 5/21/2020 2:41 PM, Steven Schveighoffer wrote:
> I even put forth a completely ignored compromise solution that would have solved 
> the problem and allowed extern(C) functions to be considered @safe by default: 
> https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html#N336968 

I did see it. I can't even get across the notion of what "undefined symbol xxxx" 
messages from the linker mean to a lot of programmers. I'll never get this one 
across. The linking process is already as complex as I dare.

BTW, two symbols resolving to the same address can be a bit awkward in some 
object formats and isn't really supported, like with COMDATs. In my experience, 
unless C or C++ compilers generate certain constructs, linkers (and debuggers) 
don't work for those constructs, whether they are documented to or not.


> This is why I consider the process a waste of time, and why I'm done participating.

The level of negativity in that thread was what caused me to stop responding, 
though I continued reading. Every reply I made produced 10 responses, an 
exponential explosion, and yet I was just repeating myself. Two sides to every 
story.

FWIW, I am going to try again with another post here, for those who want a 
convenient summary of the rationale.