DIP1028 - Rationale for accepting as is

[H. S. Teoh]

On Fri, May 22, 2020 at 10:50:02PM -0700, Walter Bright via Digitalmars-d-announce wrote:
> On 5/22/2020 10:33 AM, rikki cattermole wrote:
> > To me at least, this butchers @safe/trusted/system into a system
> > that is near useless for guarantees for an entire program.
> 
> It never attempted to guarantee safety in code that was never compiled
> with a D compiler. It's impossible to do that. No language does that.

And therefore what we need is a way of indicating verifiability up to
things outside of our control. E.g., some kind of way to express that
the safety of a piece of code is keyed upon some external function or
delegate, thus enabling @safe checks for all code except calls into said
external function/delegate.

This would work out to be practically where we're at now, except that we
don't implicitly pretend external code is @safe where there is no
verification at all.


T

-- 
Designer clothes: how to cover less by paying more.