On 19/03/2024 1:31 AM, Nick Treleaven wrote:
> On Saturday, 16 March 2024 at 19:10:56 UTC, Don Allen wrote:
>> The compiler therefore forces you to handle the unusual case, so if it happens, the result will be something under your control.
> 
> You can call `unwrap` on the Option which will panic if it's None. But that's fine, because that call makes it clear to anyone reading the code that the programmer is intentionally assuming the Option contains a value.
> 
> ...
>> Related to the above, you may also process an uninitialized value, at which point anything can happen.
> 
> It can't violate memory safety:
> 
>> Void initializers for variables with a type that may contain unsafe values (such as types with pointers) are not allowed in @safe code.
> 
> https://dlang.org/spec/declaration.html#void_init

With type state analysis you should be allowed to write, but not read uninitialized variables.

So this restriction that it isn't @safe to use them in is simply because we don't have the ability to guarantee initialization before reading can occur.

On 3/13/2024 12:50 AM, Alex wrote:
> Also, usually it leads just to some king of arithmetic exception.

It's a hardware exception, same as the null reference exception.

On 3/13/2024 9:06 AM, Petar Kirov [ZombineDev] wrote:
> Here's how TypeScript deals with this problem:
> 
> ```ts
> class A { bar() {} }
> 
> function foo(i: number) {
>      let a: A;
>      if (i) a = new A();
> 
>      if (i) a.bar(); // Error: Variable 'a' is used before being assigned.
> }
> 
> function foo2(i: number) {
>      let a: A | null = null;
>      if (i) a = new A();
> 
>      if (i) a.bar(); // Error: 'a' is possibly 'null'
> }
> 
> ```

Yes, that is one way to do it, disallowing otherwise valid programs. I ran into this with C, and there was too much C code that would be disallowed, so I didn't proceed with it.

Another issue with this approach is as soon as you pass `a` to another function, `bar(a)`, the body of `bar` doesn't know if `a` is null or not.

So this kind of analysis is not generally useful.

The same thing comes up with:

```
int* foo() { int a; return &a; }
```

Most every C compiler will detect that. But there are many ways to slip it past the compiler:

```
int* foo() { int a; int* p = &a; return bar(p); }
int* bar(int* p) { return p; }
```

which is why D came up with `scope` and `return`.

Some easy cases can be handled easily(!). But to do it reliably, DFA is required. And DFA makes the front end slow.

If one doesn't do DFA, then I will be subjected to endless bug reports where people find a case that needs DFA to resolve.

On 19/03/2024 11:46 AM, Walter Bright wrote:
> Some easy cases can be handled easily(!). But to do it reliably, DFA is required. And DFA makes the front end slow.
> 
> If one doesn't do DFA, then I will be subjected to endless bug reports where people find a case that needs DFA to resolve.

If anyone wants evidence of this, look no further than @live.

https://issues.dlang.org/show_bug.cgi?id=21923

https://issues.dlang.org/show_bug.cgi?id=21854

A memory analysis technique that requires DFA, but doesn't as it wasn't fully thought out and too specific to it.

We need semantic 4 to solve this properly: see my recent post on type state analysis in DIP ideas forum.

On Monday, 18 March 2024 at 22:27:28 UTC, Walter Bright wrote:
> It's a hardware exception, same as the null reference exception.

Yes, but language runtime can catch it via operating system mechanism and re-throw as language exception which can be handled inside code.

On Tuesday, 19 March 2024 at 08:44:29 UTC, Alex wrote:
> On Monday, 18 March 2024 at 22:27:28 UTC, Walter Bright wrote:
>> It's a hardware exception, same as the null reference exception.
>
> Yes, but language runtime can catch it via operating system mechanism and re-throw as language exception which can be handled inside code.

I wonder how these exceptions will play, if they are thrown fron nogc code...

I'd assume that you can set only one handler for each hardware exception and that handler would need to know in what function this occured, nogc or gc one, so it can halt in nogc, and throw in gc methods.

On Monday, 18 March 2024 at 21:10:40 UTC, Timon Gehr wrote:
> ```d
> import std.stdio;
> void main(){
>     bool b = void;
>     if(b) writeln("yes");
>     if(!b) writeln("no");
> }
> ```

The spec was updated:

> For a bool, only 0 and 1 are safe values.

https://dlang.org/spec/function.html#safe-values

The implementation still needs to make this an error:
https://github.com/dlang/dmd/pull/15362