Pro.safety

Pro.safety: Type-safety profile

This profile makes it easier to construct code that uses types correctly and avoids inadvertent type punning. It does so by focusing on removing the primary sources of type violations, including unsafe uses of casts and unions.

For the purposes of this section, type-safety is defined to be the property that a variable is not used in a way that doesn't obey the rules for the type of its definition. Memory accessed as a type T should not be valid memory that actually contains an object of an unrelated type U. Note that the safety is intended to be complete when combined also with Bounds safety and Lifetime safety.

An implementation of this profile shall recognize the following patterns in source code as non-conforming and issue a diagnostic.

Type safety profile summary:

• Type.1: Avoid casts:

• Don't use reinterpret_cast; A strict version of Avoid casts and prefer named casts.

• Don't use static_cast for arithmetic types; A strict version of Avoid casts and prefer named casts.
• Don't cast between pointer types where the source type and the target type are the same; A strict version of Avoid casts.
• Don't cast between pointer types when the conversion could be implicit; A strict version of Avoid casts.
• Type.2: Don't use static_cast to downcast: Use dynamic_cast instead.
• Type.3: Don't use const_cast to cast away const (i.e., at all): Don't cast away const.
• Type.4: Don't use C-style (T)expression or functional T(expression) casts: Prefer construction or named casts or T{expression}.
• Type.5: Don't use a variable before it has been initialized: always initialize.
• Type.6: Always initialize a member variable: always initialize, possibly using default constructors or default member initializers.
• Type.7: Avoid naked union: Use variant instead.
• Type.8: Avoid varargs: Don't use va_arg arguments.

Impact

With the type-safety profile you can trust that every operation is applied to a valid object. An exception can be thrown to indicate errors that cannot be detected statically (at compile time). Note that this type-safety can be complete only if we also have Bounds safety and Lifetime safety. Without those guarantees, a region of memory could be accessed independent of which object, objects, or parts of objects are stored in it.