Second Draft: Turn properties into first class accessors

[Richard (Rikki) Andrew Cattermole]

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.