If I have a struct like this:struct S{  int[10_000] data}I can access memory I'm not supposed to, even in@safe code, that is beyond the zero page:void main()@safe{   S * ptr;   ptr.data[9999] = 5;}This data could be unmapped or mapped (on my 64-bit system, it's not mapped, so a segfault still occurs). But it is a possible way to have an exploit in@safe code.I propose that if the compiler can detect at compile-time that access to a member of a struct is beyond the zero page if a pointer happens to point at null, then it should check for a null pointer (actually, it should just dereference the first word pointed at by the pointer, and trigger a segfault). It only needs to do this once if it can determine the pointer or reference will not change.If the access to the member is determined at compile-time to point within one page of the front of the struct pointer (either by knowing at compile time the index being accessed, or knowing that the struct is less than one page in size), then no instrumentation is needed.If the access cannot be determined to be within one page at compile-time, then the check should still be made during runtime.If one takes a reference to a member that is outside the one-page limit, then the same check can be performed. There are still ways to access data beyond one page without incurring a check with this scheme, but we are talking about very weird and rare code.This scheme should leave most code intact, and in rare cases, add a few null checks here and there. Note that by null check, you aren't actually checking against null, but simply using the built-in ability to segfault. So it's cheap.