On 02/05/2025 7:44 PM, Manu wrote:
> On a slight tangent; why do I need to attribute the function at all for it to check `scope` args don't escape?
> I do want to add `scope` to pointers and ref arguments, but I don't see any reason that I should have to attribute `live`... why isn't `scope` enough to enable escape analysis?

DIP1000 was the escape analysis meant to be enabled by scope.

And it can't be turned on.

On Tuesday, 29 April 2025 at 17:12:41 UTC, Walter Bright wrote:
>
> It reminds me of OOP. OOP was sold as the answer to every programming problem. Many OOP languages appeared. But, eventually, things died down and OOP became just another tool in the toolbox. D and C++ support OOP, too.

My issue with all the talk about how some features could our savior is that they are nowhere to be found in our direct competitors.

There is no surge of competitors boosted or enabled by memory-safety, borrow-checking, lack of data races or even advanced types. There is very little Rust competitors, to the point I'd argue people self-select out of the market by spending time on expensive features like those that bring no bread on the table. For example we have zero Haskell, Clojure, or Elm competitors, or even Ocaml in the audio space (that one could work there probably).

But there is a very real threat of competitors being faster with lower iteration times.

On 5/2/25 16:53, Guillaume Piolat wrote:
> On Tuesday, 29 April 2025 at 17:12:41 UTC, Walter Bright wrote:
>>
>> It reminds me of OOP. OOP was sold as the answer to every programming problem. Many OOP languages appeared. But, eventually, things died down and OOP became just another tool in the toolbox. D and C++ support OOP, too.
> 
> My issue with all the talk about how some features could our savior is that they are nowhere to be found in our direct competitors.
> 
> There is no surge of competitors boosted or enabled by memory-safety, 

(`@live` does not give you memory safety guarantees.)

> borrow-checking, lack of data races or even advanced types. There is very little Rust competitors, to the point I'd argue people self-select out of the market by spending time on expensive features like those that bring no bread on the table. For example we have zero Haskell, Clojure, or Elm competitors, or even Ocaml in the audio space (that one could work there probably).
> 
> But there is a very real threat of competitors being faster with lower iteration times.
> 
> 
Well, beyond the competitive edge that D affords you, to some extent users get what they pay/wait for and I think/hope users will be increasingly conscious of the possibility that someone might take over their computer by e.g. sending them an mp3 file that is invalid in a peculiar way.

The point of memory safety features is not really to help you write faster unsafe code with lower iteration times (though they sometimes do).

The goal is to help you write faster safe code with lower iteration times. In some domains, safety is, or will be, a requirement on the functionality of the software.

Some businesses don't care about cybersecurity until they or their users get hacked (regularly). Of course, memory corruption is only one way attackers can succeed, so advanced type system features can help. (More advanced than what you cite though, so we'll see how quickly those can be transferred to industry. It seems that usually the type system tech in popular languages is on the order of 40 years old.)

`@live` however does not give you additional hard guarantees, so I also think a priori it is not a feature on whose implementation I would spend time personally. Perhaps the work put into it can be reused for something more useful in the future.

On 5/2/25 21:48, Dukc wrote:
> On Friday, 2 May 2025 at 19:25:53 UTC, Timon Gehr wrote:
>> On 5/2/25 16:53, Guillaume Piolat wrote:
>>> On Tuesday, 29 April 2025 at 17:12:41 UTC, Walter Bright wrote:
>>> For example we have zero Haskell, Clojure, or Elm competitors
>>>
>> Of course, memory corruption is only one way attackers can succeed, so advanced type system features can help. (More advanced than what you cite though, so we'll see how quickly those can be transferred to industry.
> 
> More advanced than _Haskell_? Wat?
> 
> IMO it's absolutely mind-blowing how advanced Haskell is when you enable the more recent features such as GADTs. I feel it's already so powerful that my comprehension runs out well before the expressive power of the language, and I don't think I'm bad at comprehending programming language features.

See e.g., https://ghc.serokell.io/dh

In any case, comprehensibility is at most loosely related to expressiveness. I think Haskell with all its extensions is too complex for what it gives you in terms of expressiveness.

On 5/2/2025 12:44 AM, Manu wrote:
> On a slight tangent; why do I need to attribute the function at all for it to check `scope` args don't escape?

Because otherwise the compiler has to examine the function implementation to verify this. Doing such is called attribute inference, and D does quite a bit of that. Problems are:

1. Function declarations don't have a body, so there's no way to inspect the body.

2. Inspecting all the bodies means compilation gets slowed down quite a bit.

3. Chicken-and-egg problems when inferring attributes when there are loops in the function call flow graph.

> I do want to add `scope` to pointers and ref arguments, but I don't see any reason that I should have to attribute `live`... why isn't `scope` enough to enable escape analysis?

The DFA (Data Flow Analysis) required to determine whether a pointer is the "owner" or not at each point in the function is considerably more complex than just checking for scope-ness. DFA equations are generated and then solved iteratively.

The code required to do it is:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ob.d

which is very similar to the DFA performed by the optimizer:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/gflow.d