On 11/15/22 06:05, Siarhei Siamashka wrote:

> Ali commented that "the
> compiler cannot do anything about it in all cases and we wouldn't want
> it to spend infinite amount of time to try to determine everything".

Yes, that's my understanding.

> This sounds like he justifies the compiler's failure and accepts this as
> something normal.

Despite my lack of computer science education, I think the compiler's failure in analyzing source code to determine all bugs is "normal". I base my understanding on the "halting problem" and the "separate compilation" feature that D supports.

> The https://dlang.org/spec/memory-safe-d.html page also provides a
> rather vague statement: "@safe functions have a number of restrictions
> on what they may do and are intended to disallow operations that may
> cause memory corruption". Which kinda means that it makes some effort to
> catch some memory safety bugs.

Exactly. My understanding is that @safe attempts to remove memory corruptions. @live is being worked on to improve the situation by tracking liveness of data.

> This weasel language isn't very
> reassuring, compared to a very clear Rust documentation.

That's spot on.

Ali

Reply via email to