On Tuesday, 21 July 2020 at 13:42:15 UTC, Steven Schveighoffer
wrote:
On 7/21/20 8:34 AM, Adam D. Ruppe wrote:
The others aren't wrong about stack size limits playing some
role, but the primary reason is that it is a weird hack for
@safe, believe it or not.
...
I don't recall exactly when this was discussed but it came up
in the earlier days of @safe, I'm pretty sure it worked before
then.
I think this was discussed, but was not the reason for the
limitation. The limitation exists even in D1, which is before
@safe: https://digitalmars.com/d/1.0/arrays.html#static-arrays
I have stressed before that any access of a pointer to a large
object in @safe code should also check that the base of the
object is not within the null page (this is not currently
done). This is the only way to ensure safety.
It seems the limitation was introduced in DMD 0.123, in May 2005:
https://forum.dlang.org/post/d61jpa$1m0l$1...@digitaldaemon.com
Walter gives some justification in the post immediately following:
1) Gigantic static arrays are often either the result of a typo
or are a
newbie mistake.
2) Such require a lot of memory for the compiler to handle.
Before the OS
officially runs out of memory, it goes to greater and greater
lengths to
scavenge memory for the compiler, often bringing the computer
to its knees
in desperation.
3) D needs to be a portable language, and by capping the array
size a
program is more likely to be portable.
4) Giant arrays are reflected in a corresponding giant size for
the exe
file.
5) There simply isn't a need I can think of for such arrays.
There shouldn't
be a problem with allocating them dynamically.
I admit I thought it was an old optlink limitation, but it seems
it's basically arbitrary.
--
Simen
