On 10/26/22 8:57 PM, Walter Bright wrote:
>On 10/26/2022 1:03 AM, Walter Bright wrote:
>On 10/24/2022 6:35 PM, Steven Schveighoffer wrote:
>In a @trusted
function today, without dip1000, the above is perfectly reasonable and not invalid. Will dip1000 make it corrupt memory?
A very good question. Clearly, having code work when it is @safe, but cause memory corruption when it is marked @trusted, is the wrong solution. This should never happen. I'm not sure what the solution should be here.
[Some more thinking about the problem]
The question is when is [1,2,3] allocated on the stack, and when is it allocated on the GC heap?
Some points:
-
in C it is allocated on the stack. D's behavior to allocate it on the heap is kinda surprising in that light, even though D had such literals before C did
-
allocating on the heap means it is unusable in @nogc code
-
when writing expressions, the only way to get it on the stack is to assign it to a scope variable, which is inconvenient and inefficient
-
it runs against the idea that the simpler code should be more efficient than the complex code
Therefore, I suggest the following:
[1,2,3] is always allocated on the stack
[1,2,3].dup is always allocated on the heap
and thus, its behavior is not dependent on inference.
How we transition to this, we'll have to figure out.
Please no! We can allocate on the stack by explicitly requesting it:
int[3] = [1, 2, 3];
The issue is the DRYness of it. This has been proposed before, just:
int[$] = [1, 2, 3];
If we are going to fix something, let's fix this! It's backwards compatible too.
If anything, the compiler can just punt and say all array literals that aren't immediately assigned to static arrays are allocated on the heap. Then it's consistent.
Allocating array literals on the heap is awesome, please don't change that! D is one of the best learning languages for high-performance code because you don't have to worry at all about memory management out of the box. I'm actually OK with backends using stack allocations because it can prove they aren't escaping, why can't we just rely on that?
-Steve