On 07.06.2016 21:52, Walter Bright 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.
The fence is infinitely long, your painting speed is finite and people
will be looking at the fence mostly at the left end.
There are omissions possible either way.
...
In one way, an omission means you are potentially tracking down memory
corruption inside a huge codebase by grepping for @trusted, until you
notice that the issue is in @safe code.
In the other way, an omission means you are getting a spurious compile
error that is easily worked around.
Another issue is implementing such a spec. The "disapproved" list is how
the compiler works,
It is how the compiler fails to work.
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.
...
The compiler should work by inclusion too.
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.
...
Does not apply. The bugzilla issue can be fixed by disallowing all code
in @safe. Also, why not just close the bugzilla issue _after_ there is a
more adequate replacement?
If you want to take charge of writing such a specification DIP,
please do so.
If you think progress on this matters, why are you arguing against it?
