Contradictory justification for status quo

[Andrei Alexandrescu via Digitalmars-d]

On 2/26/15 8:21 PM, Zach the Mystic wrote:
> Can I ask you a general question about safety: If you became convinced
> that really great safety would *require* more function attributes, what
> would be the threshold for including them? I'm trying to "go the whole
> hog" with safety, but I'm paying what seems to me the necessary price --
> more parameter attributes. Some of these gains ("out!" parameters, e.g.)
> seem like they would only apply to very rare code, and yet they *must*
> be there, in order for functions to "talk" to each other accurately.
>
> Are you interested in accommodating the rare use cases for the sake of
> robust safety, or do you just want to stop at the very common use cases
> ("ref returns", e.g.)? "ref returns" will probably cover more than half
> of all use cases for memory safety. Each smaller category will require
> additions to what a function signature can contain (starting with
> expanding `return` to all reference types, e.g.), while covering a
> smaller number of actual use cases... but on the other hand, it's
> precisely because they cover fewer use cases that they will appear so
> much less often.

Safety is good to have, and the simple litmus test is if you slap @safe: 
at the top of all modules and you use no @trusted (or of course use it 
correctly), you should have memory safety, guaranteed.

A feature that is safe except for certain constructs is undesirable.

Generally having a large number of corner cases that require special 
language constructs to address is a Bad Sign.


Andrei