On Thursday, 2 December 2021 at 20:36:46 UTC, Greg Strong wrote:
> On Thursday, 2 December 2021 at 17:36:18 UTC, H. S. Teoh wrote:
>> The solution is very simple: extern(C), extern(C++), and extern anything
>> except extern(D) really, should be @system, and extern(D) (the default)
>> should be @safe.
>>
>> The real issue is convincing Walter to accept this.
>
> Yes - this seems like the most reasonable solution to me.  I don't see why it would be particularly controversial.

The last time this came up, Walter's argument against it was (iirc) that having two separate defaults for different kinds of functions is much worse for usability than having one universal default.

It's worth keeping in mind that extern(C) does not necessarily mean "written in C". So applying this rule as written would lead to some rather confusing edge cases; for example:

    import std.stdio;

    extern(C) void sayHello() // @system by default
    {
        writeln("Hello!");
    }

    void main() // @safe by default
    {
        sayHello();
        // Error: @safe function `main` cannot call @system function `sayHello`
    }

On Thu, Dec 02, 2021 at 08:36:46PM +0000, Greg Strong via Digitalmars-d wrote:
> On Thursday, 2 December 2021 at 17:36:18 UTC, H. S. Teoh wrote:
> > The solution is very simple: extern(C), extern(C++), and extern
> > anything except extern(D) really, should be @system, and extern(D)
> > (the default) should be @safe.
> > 
> > The real issue is convincing Walter to accept this.
> 
> Yes - this seems like the most reasonable solution to me.  I don't see why it would be particularly controversial.

In my mind, it's crystal clear.  But Walter refused to do it for whatever reason.  IIRC, he was the only person who rejected this.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

On Thursday, 2 December 2021 at 17:43:44 UTC, H. S. Teoh wrote:
> On Thu, Dec 02, 2021 at 11:44:28AM +0000, IGotD- via Digitalmars-d wrote:
>> On Thursday, 2 December 2021 at 11:27:01 UTC, H. S. Teoh wrote:
>> > 
>> > Another nail in the coffin of C.  Still many more nails to go, but the inevitable draws ever nearer.
> [...]
>> Would it be impossible to add bounds checking in C?
>> 
>> It's been over 4 decades and it seems like there is some profound resistance to add this.
>
> C wouldn't be C anymore once it has bounds checking.  You can bet your life that the moment somebody proposes such a thing, complaints about "efficiency" will flare up all over the intarweb.  99% of the C userbase will revolt, and the proposal will be DOA.
>
> Not to mention, how *do* you add bounds checking to a language where arrays automatically and implicitly decay to pointers?  No length information is present for you to do bounds checking on. The only way to fix this is to reengineer the language from scratch to introduce bounds-checked arrays.  But that does not fix the problems with the existing standard C libraries which take bare pointers for arrays. *Replacing* current arrays with bounds-checked ones essentially turns it into D, at which point it's not C anymore (see previous paragraph).
>
>
> T

You add it to the hardware, where every memory reference becomes a fat pointer, hence C Machines, so Lisp Machines with memory tagging, just designed for C instead.

That is how SPARC ADI, ARM MTE work.

Intel borked their MPX execution, so who knows if they will come up with something up, given that iOS and Android are now making use of hardware memory tagging.