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.

My personal opinion is that as soon as the ownership is ready, @safe should imply it. 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.

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...