On 03/01/2023 9:46 PM, Walter Bright wrote:
> On 1/1/2023 7:32 AM, Richard (Rikki) Andrew Cattermole wrote:
>> Only issue is when it doesn't give you a stack trace.
> 
> That could probably be added. After all, we already give a stack trace for some other kinds of errors.

Yeah absolutely.

Its a small QoL improvement for non-Windows systems (on Windows you can have VS attach automatically, although it should work there too!).

On 1/1/23 19:18, Walter Bright wrote:
> On 12/31/2022 7:06 PM, Timon Gehr wrote:
>> No, it absolutely, positively does not... It only ensures no null dereference takes place on each specific run. You can have screwed it up and only notice once the program is published. I know this happens because I have been a _user_ of software with this kind of problem. Notably this kind of thing happens in released versions of DMD sometimes...
> 
> You're absolutely right. And if I do a pattern match to create a non-nullable pointer, where the null arm does a fatal error if it can't deal with the null, it's the same thing.
> ...

_IF_. It's a very big IF. If you can't deal with the null, it should have been a non-null pointer in the first place. While, without even more powerful language features, this is not absolutely _always_ possible, it is _usually_ possible. This should be very easy to understand from an "engineering point of view".

> But we've both stated this same thing several times now.
> 
> 
>> That's great. However, it's somewhat aggravating to me that I am currently not actually convinced you understand what's needed to achieve that. This is because you are making statements that equate nonnull pointers in the type system to runtime hardware checking with segmentation faults.
> 
> Yes, I am doing just that.
> 
> Perhaps I can state our difference thusly. You are coming from a type theory point of view, and your position is quite right from that point of view.
> ...

I am approaching this from a practical angle, as a user and creator of software.

> I'm not saying you are wrong. You are right. But I am coming from an engineering point of view, saying that for practical purposes, the hardware check produces the same result.
> ...

This is wrong from any point of view that includes occasionally running software. I have suffered as a user from many bugs whose underlying cause is exceedingly easy to guess as just being "somebody forgot about null" and a proper type system would have obviously prevented most of those _during the initial design of the system when everyone's memory of the code base was very fresh_.

If your software crashes with a fatal segmentation fault, that's an engineering failure. Using the right tools, such as type systems, is _part_ of software engineering.

Let me translate the previous discussion to the bridge setting:

TG: I observe bridges collapsing. Maybe we should actually calculate statics during the planing phase, before building them?

WB: From a computational standpoint you are right. However, from an engineering standpoint, you can just keep building bridges. You will then learn their flaws as they collapse, which gives you exactly the same end result.

I just don't think good engineers argue in this fashion. This is exactly the kind of out-of-touch ivory tower reasoning that theorists are sometimes accused of.

> If the hardware check wasn't there, I'd be all in on your approach. Which is why I'm excited about sumtypes being used for error states.

Sure. And on some targets there is not even a hardware check. (WASM in particular would be useful to me.)

On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

I'd much rather see @attributes strategically' incorporated into D's betterC.

e.g.

module test;

extern(C) void main()
{
    import core.stdc.stdio : printf;

    //  Accesses to this array will be bounds checked at runtime.
    @checked int[5] arr = [ 0, 1, 2, 3, 4];

    for (int i = 0; i < 10; i++) // runtime will catch this error.
    {
        printf("%d\n", arr[i]);
    }

}


and btw, i really hate having to constantly change my C syntax:
i.e.

int arr[5] = { 0, 1, 2, 3, 4}; // C syntax
(into)
int[5] arr = [ 0, 1, 2, 3, 4]; // betterC syntax

That is just plain annoying.

On Wednesday, 4 January 2023 at 03:04:31 UTC, areYouSureAboutThat wrote:
> On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
>> https://news.ycombinator.com/edit?id=34084894
>>
>> I'm wondering. Should I just go ahead and implement [..] in ImportC?
>
> I'd much rather see @attributes strategically' incorporated into D's betterC.
>
> e.g.
>
> module test;
>
> extern(C) void main()
> {
>     import core.stdc.stdio : printf;
>
>     //  Accesses to this array will be bounds checked at runtime.
>     @checked int[5] arr = [ 0, 1, 2, 3, 4];
>
>     for (int i = 0; i < 10; i++) // runtime will catch this error.
>     {
>         printf("%d\n", arr[i]);
>     }
>
> }
>

This is already caught by the runtime. The idea of betterC is that you are opting into these checks.

On Wednesday, 4 January 2023 at 03:13:25 UTC, max haughton wrote:
>
> This is already caught by the runtime. The idea of betterC is that you are opting into these checks.

Except that @checked, in my example, would mean there is no way to opt-out of that check.

i.e. even in -release or -boundscheck=off, that array would always be bounds checked at runtime.

On Wednesday, 21 December 2022 at 19:31:22 UTC, Walter Bright wrote:
>
> ....
> ......
>
> Checked C:
>
>     int a[5] = { 0, 1, 2, 3, 4};
>     _Array_ptr<int> p : count(5) = a;  // p points to 5 elements.
>
> My proposal for C:
>
>     int a[5] = { 0, 1, 2, 3, 4};
>     int p[..] = a;  // p points to 5 elements.
>

I've decieded that I like neither:

_Array_ptr<int> p
(nor)
int p[..] = a;

I prefer:

int a[5] = { 0, 1, 2, 3, 4};
@checked int p[] = a;  // p points to 5 elements.

@attributes would be a great way of extending the C language without introducing odd looking syntax, like Microsofts, that makes me wanna puke, or yours, that makes me look at it for 30 mintutes, trying to work our .. what does [..] actually mean...

On Wednesday, 4 January 2023 at 03:42:42 UTC, areYouSureAboutThat wrote:
>

another example:

/* This function searches for an integer in an array.
   If it finds the integer, it returns the index in the
   array where the integer occurs. Otherwise, it returns -1
*/

//int find (int key , array_ptr <int > a : count ( len ), int len ) // Microsoft Checked C syntax.
int find (int key , @checked int a[] : len, int len ) // alternative syntax using @attributes
{
    for (int i = 0; i < len; i ++)
    {
        // NOTE: a[i] is bounds checked.
        // The checking ensures that i is between 0 and len .
        if (a[i] == key )
        {
            return i;
        }
    }
    return -1;
}

On Wednesday, 4 January 2023 at 03:42:42 UTC, areYouSureAboutThat wrote:
> On Wednesday, 21 December 2022 at 19:31:22 UTC, Walter Bright wrote:
>>
>> ....
>> ......
>>
>> Checked C:
>>
>>     int a[5] = { 0, 1, 2, 3, 4};
>>     _Array_ptr<int> p : count(5) = a;  // p points to 5 elements.
>>
>> My proposal for C:
>>
>>     int a[5] = { 0, 1, 2, 3, 4};
>>     int p[..] = a;  // p points to 5 elements.
>>
>
> I've decieded that I like neither:
>
> _Array_ptr<int> p
> (nor)
> int p[..] = a;
>
> I prefer:
>
> int a[5] = { 0, 1, 2, 3, 4};
> @checked int p[] = a;  // p points to 5 elements.
>
> @attributes would be a great way of extending the C language without introducing odd looking syntax, like Microsofts, that makes me wanna puke, or yours, that makes me look at it for 30 mintutes, trying to work our .. what does [..] actually mean...

In fact this seems reasonable, and with this what about changed it to: __checked, then:

C programmers use #define when needed, i.e:

#define __checked ;

__checked int p[] = a;  // p points to 5 elements.

Of course using #IF #ELSE for defining it when compiling in C vs D.

Matheus.

On 1/3/2023 1:42 AM, jonatjano wrote:
> I think you should do it, you're losing much more time arguing about it's value than if you did it from the start
> People want you to work on this and that but argue so much with you on a non-breaking addition that you don't have the time to work at all

Every post I make spawns multiple leaves with everyone repeating their same positions. At some point any progress grinds to a halt.

> As far as I understand it's nothing more than a syntax for D slices into betterC, which mean most of the code is already written

That's right.

> (maybe it could use D slice syntax directly for a better transition from betterC to full D if wanted?)

The D syntax won't work in C, which is why I changed it slightly.