But its usage as expression is not the most nice, so it's probably better to
disallow this usage:
void foo(int[] a) {}
main() {
foo(new[5] = 5);
}

Might as well change foo to accept a size_t length and initializer,
and let it create an array on the stack or heap, whichever it thinks
is more efficient or safer. Why pass a new heap-allocated array which
you don't have the handle to outside of foo? What's the use-case for
this example?

I thought about "void new", but I'd rather drop that idea. There's
also that opinion that letting 'new' into the language was a mistake.
I wouldn't mind a template instead of syntax sugar. I'd be fine with:
auto foo = voidNew!(float[][])(4, 10); // float[10][4], no initializer
auto bar = initNew!(float[][])(4, 10, 5.5); // float[10][4], all
initialized to 5.5
or make the initializer a CT argument, I think this would be more readable:
auto bar = initNew!(float[][], 5.5)(4, 10); // float[10][4], all
initialized to 5.5
No need to mess with the compiler, can be implemented with D's
template features. We can have this implemented and unittested in a
day, compared to hacking the compiler and worrying about bugs.

Why pass a new heap-allocated array which
you don't have the handle to outside of foo? What's the use-case for
this example?

It's a minimal example to show a syntax, it's not an use case.

No need to mess with the compiler,

With this attitude probably you are able to remove half of the stuff present in
D today (and sometimes this is good. After all this time I have changed my mind
a little and I don't think associative arrays are so good as built-in in a
system language. What's needed is just a general built-in syntax to define AA
literals, a syntax usable for user-defined types too).
Bye,
bearophile

With this attitude probably you are able to remove half of the stuff present
in D today.

:) Well I was talking about adding features, not turning existing ones
to library code.
Another benefit of adding a feature as a library function first
instead of a language feature is you get to test the function first
and figure out if you really use it that often. If it becomes too
tiring to use the function then implementing some syntax sugar might
be better.

But maybe you don't use it that often because using the function is too
tiring ;)

With this attitude probably you are able to remove half of the stuff present
in D today.

:) Well I was talking about adding features, not turning existing ones
to library code.
Another benefit of adding a feature as a library function first
instead of a language feature is you get to test the function first
and figure out if you really use it that often. If it becomes too
tiring to use the function then implementing some syntax sugar might
be better.