On Monday, 23 September 2019 at 22:13:11 UTC, Walter Bright wrote:
> Otherwise there is simply no way to incrementally adopt @live.

Yes, that's the problem.

> @live rules only apply to the internals of the @live function. At some point there must be a presumption that functions that call the @live function or the functions the @live function calls conform at least to the @live function interface.

The problem is, since the compiler can't check that non-@live functions conform to the @live invariants, it has to trust the developer, which severely weakens @safe (if nothing else, because it makes it possible for someone to do a memory corruption in a codebase with no @system or @trusted functions).

On Monday, 23 September 2019 at 22:13:11 UTC, Walter Bright wrote:
> On 9/23/2019 1:34 AM, Olivier FAURE wrote:
>> Given @live as you described it, non-@live functions calling @live functions would have to be @system or @trusted, which isn't a state you want half your codebase to be in.
>
> @live rules only apply to the internals of the @live function. At some point there must be a presumption that functions that call the @live function or the functions the @live function calls conform at least to the @live function interface.
>
> Otherwise there is simply no way to incrementally adopt @live.

The @safe by default dip is part of the plan of adopting @live?

-Alex

On 9/24/2019 12:50 PM, 12345swordy wrote:
> The @safe by default dip is part of the plan of adopting @live?

No.

On 9/24/2019 1:30 AM, Olivier FAURE wrote:
> The problem is, since the compiler can't check that non-@live functions conform to the @live invariants, it has to trust the developer, which severely weakens @safe (if nothing else, because it makes it possible for someone to do a memory corruption in a codebase with no @system or @trusted functions).

It wouldn't be any less safe than it is now. Remember, @live adds a layer of more checking, not less.