There is a guarantee that I want for this.

The compiler will guarantee that for every assignment that has a paired read, that there will be no other reads.

```d
@property {
    int value();
    void value(int);
}
```

```d
value += 2 + value;
```

Would be:

```d
{
    int __generatedName = value;
    value(__generatedName + 2 + __generatedName);
}
```

Not:

```d
value(value + 2 + value);
```

Furthermore, the loaded value must not escape the load statement.

This may seem unnecessary, but without this, I cannot think of a way for escape analysis to work with it.

With these guarantees, we might be able to special case it just enough for it to be modelable.

On Thursday, 6 February 2025 at 00:52:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> There is a guarantee that I want for this.
>
> The compiler will guarantee that for every assignment that has a paired read, that there will be no other reads.
>
> ```d
> @property {
>     int value();
>     void value(int);
> }
> ```
>
> ```d
> value += 2 + value;
> ```
>
> Would be:
>
> ```d
> {
>     int __generatedName = value;
>     value(__generatedName + 2 + __generatedName);
> }
> ```

Descending into the RHS expression and rewriting occurences of `value` there is complete insanity. Not only does it fall apart the instant you try to nest an expression like this recursively:

    value += (value += 2); // what now??

...it also has the potential to remove observable side effects from a program, which is, of course, completely unacceptable.

At the end of the day, all of this @property stuff is just syntax sugar for normal function calls. If you can't figure out how to make escape analysis work with function calls, that's a problem for your design. Leave @property out of it.

On 06/02/2025 4:34 PM, Paul Backus wrote:
> ...it also has the potential to remove observable side effects from a program, which is, of course, completely unacceptable.

In this case, what I am suggesting that yes, we must remove side effects that involve an owning objects lifetime.

If we do not, it will not be equivalent to operator overloads in terms of lifetime management and that is quite a bad situation to be in.

A ``@property`` method is for all intents and purposes is a borrowing action. Even if it isn't returning by-ref. Although some people may want to restrict this notion to only if you assign like this DIP proposes the ability to do so.

On Thursday, 6 February 2025 at 04:14:14 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 06/02/2025 4:34 PM, Paul Backus wrote:
>> ...it also has the potential to remove observable side effects from a program, which is, of course, completely unacceptable.
>
> In this case, what I am suggesting that yes, we must remove side effects that involve an owning objects lifetime.
>
> If we do not, it will not be equivalent to operator overloads in terms of lifetime management and that is quite a bad situation to be in.
>
> A ``@property`` method is for all intents and purposes is a borrowing action. Even if it isn't returning by-ref. Although some people may want to restrict this notion to only if you assign like this DIP proposes the ability to do so.

All of this stuff you're talking about is just function calls. Operator overloading is function calls. @property is function calls.

A function call is one of the most basic, fundamental language constructs that there is. If your design for escape analysis can't handle function calls, then you need a better design.

The fact that your current design is (apparently) deficient should not impede us from adding useful language features.

On 06/02/2025 5:19 PM, Paul Backus wrote:
> On Thursday, 6 February 2025 at 04:14:14 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 06/02/2025 4:34 PM, Paul Backus wrote:
>>> ...it also has the potential to remove observable side effects from a program, which is, of course, completely unacceptable.
>>
>> In this case, what I am suggesting that yes, we must remove side effects that involve an owning objects lifetime.
>>
>> If we do not, it will not be equivalent to operator overloads in terms of lifetime management and that is quite a bad situation to be in.
>>
>> A ``@property`` method is for all intents and purposes is a borrowing action. Even if it isn't returning by-ref. Although some people may want to restrict this notion to only if you assign like this DIP proposes the ability to do so.
> 
> All of this stuff you're talking about is just function calls. Operator overloading is function calls. @property is function calls.
> 
> A function call is one of the most basic, fundamental language constructs that there is. If your design for escape analysis can't handle function calls, then you need a better design.
> 
> The fact that your current design is (apparently) deficient should not impede us from adding useful language features.

This has nothing to do with with what my design can or cannot do (although it could catch it, it would be more picky is all).

I bring this stuff up to make sure we have enough wiggle room in _any_ design to ensure understandable behavior without safety issues.