On 6/7/2016 12:52 PM, Walter Bright via Digitalmars-d wrote:
On 6/7/2016 11:32 AM, Timon Gehr wrote:
The @safe subset should be specified and
implemented by inclusion, such that it is obvious that it does the
right thing.
I don't know what's 'unspecific' about this.
Closing holes one-by-one is not the
right approach here. You don't know when you are done and might never be.
I don't see how it is any different painting the fence from one
direction or the other. There are omissions possible either way.
Yes, either direction has the probability of being incomplete. However,
when the disallow by default and allow only explicitly activities is
_far_ more correct in the face of omissions. In the case of an omission
of something that should be allowed, you haven't discovered a violation
of safety, you've discovered a place to allow additional safe code.
To use an analogy, would you trust a security model where the list of
people not allowed to withdraw from your bank account be a whitelist or
a blacklist?
Another issue is implementing such a spec. The "disapproved" list is how
the compiler works, and makes it reasonably straightforward to check the
implementation against the list. It's quite a mess to try to tag
everything the compiler does with approved/disapproved, so you wind up
in exactly the same boat anyway.
In any case, writing such a large specification covering every semantic
action of the of the language is way, way beyond being a bugzilla issue.
Yes, it's hard to implement. Shrug, you signed up for it.
