[OneWingedShark]

> I suspect, though, that memory safety is one of the most important kinds of safety.

I don't. It seems to me like "memory-safety" is a response to the legacy of C and "C-compatibility) WRT poor behavior/respect of types; example: int/address punning, int/boolean punning, array/pointer punning, etc. (NUL-terminated stings could fit here, too as they're a consequence of C's address/array confusion.)

Contrary to this, would be correct typing. Consider SQL-injection and how the "best practice" is to never take data from the user... well we can take data from the user AND ensure there's no possibility of injection:

    Subtype Numeric is String
      with Dynamic_Predicate => (for all C of Numeric => C in '0'..'9'),
           Predicate_Falure  => raise Constraint_Error with "'" & Numeric &"' is not numeric.";
    --...
    Count : Numeric renames Get_User_Value;
    --...
    return Query("SELECT \* FROM Some_Table WHERE Count=" & Count & ";");

The above is perfectly safe because the constraint imposed prohibits the SQL-injection... and you can even enforce something like SQL_Escaping:

  PACKAGE Example IS
    -- The only way to get a value of ESCAPED_STRING is via calling Create.
    Type Escaped_String is private;
    Function Create( X:String ) return Escaped_String;
  PRIVATE
    Type Escaped_String is new String;
    Function Create( X:String ) return Escaped_String is
    ( SQL_Escape(X) );
  END Example;