On 14/06/2022 10:49 AM, Walter Bright wrote:
> On 6/10/2022 5:46 AM, Steven Schveighoffer wrote:
>> I would love to see a viable safe-by-default DIP get added.
> 
> At least we can agree on that!

I would love to see a PR turn on attribute inference for all functions.

Who knows, we might be closer to having this work for most code than we think!

On 6/9/2022 7:46 AM, Dennis wrote:
> A pointer to a local is guaranteed to be a dangling pointer when you return it, while a `scope` pointer is not guaranteed to be memory with limited lifetime when you return it. `scope` is only a conservative compile-time approximation of what's actually happening, which makes it susceptible to false positives:
> 
> ```D
> int* f(int x) @safe {
>      int* p = &x; // p is inferred scope here
>      p = new int; // p is no longer pointing to stack memory
>      return p;    // Error: scope variable `p` may not be returned
> }
> ```
> This function could be permitted as @system or @trusted code.

I suggest there is little point to permitting it, as good style would expect that a different variable be used for each purpose, rather than "recycling" an existing variable.

I.e.:


```D
int* f(int x) @safe {
    int* p = &x;
    int* q = new int;
    return q;
}
```

On 6/9/2022 8:30 AM, Steven Schveighoffer wrote:
> What is not OK is the compiler turning actual requests for GC allocation into stack allocations based on that.
It's necessary for D generated code to be competitive.

On 14.06.22 00:52, Walter Bright wrote:
> On 6/10/2022 4:59 PM, Timon Gehr wrote:
>> On 6/10/22 05:07, Walter Bright wrote:
>>> This entire thread is what happens with "not at all".
>> Well, I contest that. It's not even closely related. This is an issue concerning `@system` code. What's the default has not much at all to do with it.
> 
> Steven is compiling ordinary code with the default, when there is no obvious reason why it should be system code.
> ...

The obvious reason why Steven's example should be `@system` code is because that's where he is observing the issue.

> @system code should be relatively rare.

Steven made very clear in the original post that he's aware that this is `@system` code. It's not annotated because `@system` is currently the default.

On 14.06.22 00:53, Walter Bright wrote:
> On 6/9/2022 5:44 AM, John Colvin wrote:
>> That is their fault
> 
> If the language encourages it, it's the language's fault.

Exactly. You have literally been arguing in favor of the language doing this exact faulty thing _implicitly by default_. _That's_ what encouragement looks like.

On Monday, 13 June 2022 at 22:56:11 UTC, Walter Bright wrote:
> The D compiler *does* keep track of this when it does attribute inference. Attribute inference is not currently done for regular functions because of the risk of mismatch between a function declaration and a function definition that may arise because of inference.

It'd cause a linker error though, right? This isn't really much different than any other mismatched header - and since we have dmd -H, it seems manageable.

I'll write a blog about this when I have time though. Been swamped with work lately but I do think there's some cases we have to be careful of but it should be doable.

On Monday, 13 June 2022 at 23:59:56 UTC, Walter Bright wrote:
> On 6/9/2022 8:30 AM, Steven Schveighoffer wrote:
>> What is not OK is the compiler turning actual requests for GC allocation into stack allocations based on that.
> It's necessary for D generated code to be competitive.

As I work at a much higher level, conceptually, I've always accepted the proposition that stack allocation is much faster than heap allocation.

But I am curious.

How does one, these days, compare the performance of stack allocation vs heap allocation?

Are you also factoring into your argument (for competitively generated code), de-allocation? In which case, if there is a lot of spare memory, how does one compare the speed of stack de-allocation to gc de-allocation (since the more spare memory, the less need to GC deallocate).

I am surprised, if it's true, that modern hardware still can't provide heap based allocation at least as fast as stack based allocation. Of course, I have no idea - it's not my area, by a long shot - I'm just curious whether its really true, these days, or it's just something we accept to be true, cause it used to be true?

On 14/06/2022 1:45 PM, forkit wrote:
> I am surprised, if it's true, that modern hardware still can't provide heap based allocation at least as fast as stack based allocation. Of course, I have no idea - it's not my area, by a long shot - I'm just curious whether its really true, these days, or it's just something we accept to be true, cause it used to be true?

There is no such thing as hardware assisted memory allocation.

Memory allocators were data structures in 1980, and they still are today.

The only difference being sbrk has now been deprecated by POSIX standard.

https://www.amazon.com/Structure-Techniques-Addison-Wesley-computer-science/dp/0201072564

https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/0367659247