I think I still need more feedback before I can properly develop this idea into a DIP. Particularly, I need to know if there are any problems with the lowering discussed above.

On Wednesday, 17 July 2024 at 08:23:45 UTC, IchorDev wrote:

int[$] foo(size_t i){
  int[i] output;
  foreach(...){
    ...
  }
  return output;
}

int[] output = (cast(int*)alloca(i * int.sizeof))[0..i];

Why not this:

scope xs = new int[](n);

With the same guarantees of allocation elision as scope xs = [ 1, 2, 3 ];?

On Monday, 12 August 2024 at 10:37:21 UTC, Quirin Schroll wrote:

int[$] foo(size_t i){
  int[i] output;
  foreach(...){
    ...
  }
  return output;
}

int[] output = (cast(int*)alloca(i * int.sizeof))[0..i];

scope xs = new int[](n);

new = GC heap allocation

So it doesn't make sense to read that line

A value is a value, no new keyword, please, besides, in my custom runtime, there is no class, no new, no GC and more importantly, no TypeInfo

D's biggest mistake was to make this GC allocated without requiring new

I hope this gets fixed with an Edition, because it is cringe

On Monday, 12 August 2024 at 17:42:11 UTC, ryuukk_ wrote:

int[$] foo(size_t i){
  int[i] output;
  foreach(...){
    ...
  }
  return output;
}

int[] output = (cast(int*)alloca(i * int.sizeof))[0..i];

scope xs = new int[](n);

Nonsense. Try this (use -dip1000):

void f(scope Object) @safe @nogc { }
void main() @nogc @safe
{
    scope o = new Object;
    f(o);
}

Oddly, new rather means: Creates a reference type. It does not mean: Allocates on the GC.

What you’re basically saying is: You don’t use D; you use a personal language based on D.

Funnily enough, C#12 added collection expressions which are basically what D had all along. In particular, no use of new.

Some people overly care about GC and allocations. D is a GC language. It has facilities to statically ensure some parts of a program are free of GC allocations, probably for the purpose of optimizing hot spots. Most of Phobos is not written with @nogc in mind – or nothrow for that matter. For example, I recently fixed lockstep so that it is @safe (and pure), but not @nogc or nothrow. That is not due to the task it accomplishes, but because it uses enforce.

On Tuesday, 13 August 2024 at 09:55:28 UTC, Quirin Schroll wrote:

int[$] foo(size_t i){
  int[i] output;
  foreach(...){
    ...
  }
  return output;
}

int[] output = (cast(int*)alloca(i * int.sizeof))[0..i];

scope xs = new int[](n);

void f(scope Object) @safe @nogc { }
void main() @nogc @safe
{
    scope o = new Object;
    f(o);
}

I don't use a personal language based on D, i use D with a custom runtime, big difference, because of that i can target both consoles and WebAssembly, you can't with your C#/Java'd D

It would have never been an issue if D made the right call of not expecting [1,2,3] to be GC allocated without requiring new, fix that mistake, don't put another mistake on top of it

C# is a JIT/GC language

D was not, it slowly became one because nobody dared calling out the GC and Java people, they have ruined its reputation during a timeline that made Rust popular and now Zig..

It's easy to become C#, it's harder for C# to become D or even Rust (stackalloc :vomit:)

On Tuesday, 13 August 2024 at 10:53:40 UTC, ryuukk_ wrote:

Why can’t any given video games console use DRuntime?

I agree that new on a stack allocation is utterly confusing. One of the first things you’re taught about D and how to avoid heap allocations is that new always heap allocates. Obviously it was just done that way so that it can just fall back to a heap allocation if you turn off DIP1000, but it’s not nice when you ONLY ever want a stack allocation. I hope that element of DIP1000’s syntax will be replaced by something more amicable.
Prepending allocating array literals with new is interesting. Sometimes it’s even optimised to be on the stack anyway. And what about x ~ y? There are some scenarios where hiding a heap allocation just makes things look nicer. That said, using array literals to set static arrays in @nogc code is easy to get wrong, resulting in a confusing error. And in BetterC the necessary array copy function sometimes fails to manifest, so you get a linker error.

Uh… D didn’t become a JIT language though.

I think I’m going to keep an eye on what happens at the DIP1000 meeting and see where to go with this from there. Maybe they’ll have come up with something much better than this or scope, or not.