Some errors can't be autodetected from sources - array bounds, invalid pointers, access to destroyed objects, wrong typecast, wrong record alignment.. It's shame, that for 15-20 years of language developmant and usage, it still don't have any protection from routines, that can cause random critical runtime errors. Smart pointers for objects by default can solve most casual troubles. In 90'th with limited computing resources, extra runtime checks was burdening, but now it's not a problem even for pocket devices. Difference in performance between debug and release builds is unnoticable.
Well, how about:
- Using Low() and High() and Length() for arrays. If you don't,
you are the cause of your problems
- Testing Assigned(), Assert() and nil for pointers will help
- Hard - wrong - type casts can never be made safe. That is a programmer instruction by definition.
- Smart pointers should not be on by default, they are possible though, in trunk.
- Record alignment is a programmers task. If writing to/from a storage medium is required a record should be packed and the programmer should take care of the optimum layout, otherwise it should be CPU/FPU/OS alignment dependent. Simple.
If you have indeed 15-20 years of experience.... well, use the language features that are already there..
Some runtime checks are possible, but for e.g. a hard cast that is not possible.