Would the ownership model make D lang as complicated as Rust?

[Timon Gehr]

On 18.11.20 03:23, Max Haughton wrote:
> On Wednesday, 18 November 2020 at 01:38:27 UTC, Timon Gehr wrote:
>> On 18.11.20 02:19, Walter Bright wrote:
>>> On 11/15/2020 6:11 AM, donallen wrote:
>>>> [...]
>>>
>>> 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.
> 
> I think in the first case it would not be unreasonable to not allow a 
> @live function (in @safe code at least) to be called where it cannot be 
> guaranteed to be safe even in a more conservative analysis that what 
> @live ends up being.
> ...

Sure, but then you get two incompatible sub-languages, there's no good 
reason to want that and I think Walter agrees.

> My personal opinion is that as soon as the ownership is ready, @safe 
> should imply it.

Absolutely not. @live is incompatible with tracing GC, but this is one 
of the main ways current D achieves memory safety. It would be a huge 
mess without any justification.

> Assuming it is properly specified it seems like a 
> better way of doing things than having a big list of do's and dont's for 
> safe code.

Or, you know, just add borrowing and ownership properly without botching 
the design. None of this fooling around is actually necessary...