[cap-talk] definition of the term "safe language"

[Rob Meijer]

On Sat, April 10, 2010 21:22, Jonathan S. Shapiro wrote:
> It isn't pointers that make C# unsafe. It's pointer arithmetic. A
> distinction, regrettably, that seems to have been neglected in the
> specification of C#.
>

Maybe the definition of a safe language would simply be a language
'without' unsafe constructs like pointer arithmetic. We may actually need
two categories of 'unsafe' languages. Languages that sufficiently
abstraction rich to allow a usable and verifiable subset and/or coding
convention that is without unsafe constructs. and languages that are not.

Why do we care about 'memory' safety? Primary because it breaks the
encapsulation abstraction. So in effect we should talk about encapsulation
safety. Without the encapsulation abstraction there seems to be no real
need for memory safety. This from an abstractions point of view would for
example make C more of a safe language than C++. C offers pointer
arithmetic and (old style) casting, but offers no encapsulation, so there
is no abstraction broken by it. C++ offers abstractions for encapsulation,
while still offering the C constructs of pointer arithmetic and (old
style) casting, and the more explicit reinterpret_cast and the likes. This
would make C++ the less secure language of the two.
On the other hand, C++ offers alternatives that allow a developer to avoid
pointer arithmetic, old style cast and reinterpret_cast constructs. That
means the C++ language should have a usable subset that would fully honor
the encapsulation abstraction that C++ offers. In that sense, C++ would be
the safer of the two, at least if we assume that the encapsulation
abstraction increases safety. The question becomes, 'why do we think
encapsulation is important?', I think we agree that its important for many
reasons, but does this importance equate safety? And does the existence of
a safe subset make a language safe, or does the pure presence of
encapsulation unsafe concepts in a language make the language unsafe.
If so, than no language that allows either global variables or static
class level variables should be considered unsafe. Next to encapsulation,
there are other aspects to software were safety may be relevant. For
example exception safety. While there are language constructs in some
languages that make exception safety easier to achieve, they never seem to
be mandatory (I'm no languages specialist, so there may be languages that
are mandatory exception safe). So if we don't include the concept of 'safe
subset', while on the other hand want some 'generic' safe label, there
seem to be a lot of prerequisites for a language to fit such a label.
Just a few:

* type-safety (no reinterpret casting)
* encapsulation safety (no pointer arithmetic, no statics, no globals)
* exception safety (mandatory RAI ?)
* parallelism safety ( no non-thread local resources ?, mandatory RAI ?,
asynchronous languages ? )

I'm probably still missing quite a few, but already no main stream
language seems to fit the bill.