On Sunday, 29 May 2022 at 08:14:18 UTC, rikki cattermole wrote:

It cannot both be simple and low on false positives. Anyway, I dont really like the concept of DIP1000.

It basically means that any required change to a function can lead to a situation where one has to slap @trusted on it.

On Sunday, 29 May 2022 at 08:52:55 UTC, rikki cattermole wrote:

Yes, @trusted is ok when you can limit it to some specific module/class, but if you end up sprinkling it around then there is no point to @safe anymore.

On Sunday, 29 May 2022 at 09:21:16 UTC, rikki cattermole wrote:

Yes, and that is why the idea of a simple solution doesn't work. I seldom make mistakes in functions without loops.

@safe is most valuable in functions that are "complicated" (containing loops or other intricacies).

Some overhead in @safe is ok, because most applications don't need to be faster than Java in 95% of the code. So if you make 95% @safe then you only need to be careful with the remaining 5%.

Which is kinda how it works with C now, people write C libraries and use those with high level languages. But it is more convenient with one unified language (and that could make D attractive for Linux GUI applications).

On Sunday, 29 May 2022 at 08:52:55 UTC, rikki cattermole wrote:

I hope I didn't sound too negative, as I am 100% supportive of what you have said in other treads about ARC or adding constraints that enable a more advanced GC. (Or possibly my idea of having ARC for shared and GC for non-shared).

It is just not fruitful to try to make @system-type code @safe as that means Rust or beyond, and those that want that have already moved to Rust. And even if D could do the same as Rust then it would take 15 years to get there and then we compete with next gen static analysis for C++33, Rust 2.0 and Go 3.0… And if D is only going halfway to where Rust is then there will be endless complaints and people will just switch over to Rust to benefit from their ecosystem.

So this angle is a big drain on language evolution.

D could achieve so much more by providing some cool features for making it easier to write @trusted code that actually can be trusted.

All this work people talk about regarding static analysis and advanced type system features could be done as optimizations on a simpler stable language. With higher payoff.

On Sunday, 29 May 2022 at 12:11:01 UTC, rikki cattermole wrote:

I guess what I am saying is something like this:

I think you would get better yield for your time investment by pursuing how to add barriers and figuring out how one could write @trusted code in such a landscape than anything related to advanced escape analysis in the context of verification of D code (optimization is ok, because then you will choose a best effort strategy, verification is all-or-nothing).

To understand what is needed for solid escape analysis, let us take the two-element queue example. You could unroll the loop. Replace a[0] with a0, a[1] with a1 and all a[i] accesses with a conditional (or switch). Then analyse this with an algorithm/solver that can deal with branches. Or something along these lines. A lot of machinery even for the simplest datastructure! And then we have the slice scenarios with aliasing, where modifying the content of one slice could modify basically any other parameter.

It would be so much easier to just add @stack as an optimization hint where you want something to be put on the stack, and let the compiler generate a report of where it failed, why and how to improve the code.

(For DIP1000 to make sense it must be a able to deal with more complexity than most of your code, otherwise it will break down whenever you need to modify existing code.)

On Sunday, 29 May 2022 at 12:57:01 UTC, rikki cattermole wrote:

ARC could work with -betterC.