November 17, 2020
On Tuesday, 17 November 2020 at 18:02:00 UTC, Max Haughton wrote:
> Rice's theorem means you can't just let the compiler do it for you,

We probably can't, but since we are talking finite entities you can enumerate all possibilities in finite time, so you need a different line of argumentation I think.

 > What Rust shows us that a
> conservative approach (i.e. annotations from the programmer and the exact rules the borrow checker allows) is more than enough to guarantee safety and manage memory productively.

Yes, and there are many other ways to annotate and constrain the search space. Clearly not trivial... But this is not the end, it is the beginning...

> D is already going in the right direction, the only issue really is that (as they are now) pointers are insufficiently expressive to be both safe and (say) act like C++ smart

Yes, you need a type system that differentiate more to make it tractable...



November 17, 2020
On Tuesday, 17 November 2020 at 17:00:12 UTC, donallen wrote:
>> Even if the language dies tomorrow, it has already made a mark on Swift, D, Chapel, ParaSail, C++, Haskell, Idris(2), F*, Dafny and probably others.
>>
>
> I'd be very interested in knowing where you think Rust has influenced Haskell. There is certainly a lot of influence in the other direction, e.g., Haskell classes -> Rust traits.

Check Linear Haskell.
November 17, 2020
On 11/15/2020 1:21 AM, rikki cattermole wrote:
> If you could turn on @live for specific variables, then there would be a point.

I considered that, and concluded that it was too inconvenient to be used widely.

November 17, 2020
On 11/15/2020 1:29 AM, Sebastiaan Koppe wrote:
> I thought @live can avoid refs count with regard to resource management, and still get deterministic destruction. That would be valuable even if there is a gc around.

If you're using deterministic destruction, you don't need a gc :-)

Anyhow, we can pick this up again after seeing my presentation on it at #DConfOnline
November 17, 2020
On 11/15/2020 6:11 AM, donallen wrote:
> I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.

It's a similar approach to how D does functional programming. You can do FP in D on a totally incremental approach, function by function. And just like doing OOP in D, you can use it in parts of your program and not in other parts.

November 18, 2020
On 18/11/2020 2:14 PM, Walter Bright wrote:
> On 11/15/2020 1:21 AM, rikki cattermole wrote:
>> If you could turn on @live for specific variables, then there would be a point.
> 
> I considered that, and concluded that it was too inconvenient to be used widely.

Unfortunately this is the kind of memory safety that users, as in non-programmers care about.

They don't want zombie processes with ghost windows that they can't do anything with on top of every other window.

It is one thing for an individual program to misbehave, it is another for it to hurt the system.
November 17, 2020
On 11/15/2020 6:34 AM, Timon Gehr wrote:
> And an unsound interface between the two so you can have your O/B and safety type checks and even get the luxury of some memory corruption anyway.

In Rust there are unsafe (i.e. unsound) functions, too. It's not possible to make Rust work without them.
November 18, 2020
On Wednesday, 18 November 2020 at 01:21:12 UTC, Walter Bright wrote:
> On 11/15/2020 6:34 AM, Timon Gehr wrote:
>> And an unsound interface between the two so you can have your O/B and safety type checks and even get the luxury of some memory corruption anyway.
>
> In Rust there are unsafe (i.e. unsound) functions, too. It's not possible to make Rust work without them.

In Rust, the borrow checker is still enabled in unsafe functions:

> You can take five actions in unsafe Rust, called unsafe superpowers, that you can’t in safe Rust. Those superpowers include the ability to:
>
>    * Dereference a raw pointer
>    * Call an unsafe function or method
>    * Access or modify a mutable static variable
>    * Implement an unsafe trait
>    * Access fields of unions
>
> It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked.

Source: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
November 18, 2020
On 18.11.20 02:21, Walter Bright wrote:
> On 11/15/2020 6:34 AM, Timon Gehr wrote:
>> And an unsound interface between the two so you can have your O/B and safety type checks and even get the luxury of some memory corruption anyway.
> 
> In Rust there are unsafe (i.e. unsound) functions, too. It's not possible to make Rust work without them.

`unsafe` functions are not unsound, as they don't claim to be safe.
November 18, 2020
On 18.11.20 02:19, Walter Bright wrote:
> On 11/15/2020 6:11 AM, donallen wrote:
>> I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.
> 
> It's a similar approach to how D does functional programming. You can do FP in D on a totally incremental approach, function by function. And just like doing OOP in D, you can use it in parts of your program and not in other parts.
> 

This works for `pure`, but not `@live`, because it is not an issue for an impure function to call a `pure` one, but if a non-`@live` function calls a `@live` one, the arguments may violate invariants that `@live` users want to rely on.

In any case, `pure` is transitive. `@live` is not even transitive, so you get the same problems the other way around.