On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright
wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not
allowed and
adding to the list when new holes are discovered
https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced
Currently, there are zero bugzilla issues tagged with 'safe'.
Please file
bugzilla issues for which ones are discovered and tag them!
I don't even know what to answer to that. We are clearly
talking past each other
here, and I have no idea how to convey the message in a better
way.
1. A long list of problems with @safe has been asserted, but I
have not been able to elicit any enumeration of them, so the
extent of this problem is completely unknown.
2. The definition of @safe in the spec is asserted to be
utterly wrong, but no corrected definition has been proposed.
3. A new approach to designing @safe has been proposed in vague
terms, but nothing specific and no offers of help to flesh it
out.
From my perspective, it is like bug reports I'd often get for
the compiler that consisted solely of:
"Your compiler doesn't work."
It's just not helpful. There's nothing I can do with that.
Also, D is a collaborative effort. If there's an issue that
engages your interest, step up and help out. I simply cannot do
everything. This n.g. is full of "you should do this, you
should do that" largely directed at me. You guys want things to
happen, make them happen!
You two speak different languages here, I'll try to translate:
Basically deadalnix argues that memory safety cannot be checked
by a machine (there's a proof for that) and as @safe-ness can be
checked it obviously is not equivalent to memory safety. Further
*any* definition of @safe-ness that can be expressed by a finite
set of mathematical rules will not be equivalent to memory safety.
Then the big misunderstanding is the "equivalence". Equivalence
means that
1) @safe implies memory-safe
2) !@safe implies !memory-safe
Clearly Walter is only talking about 1), and there is no reason
why you couldn't have a @safe-ness check that implies
memory-safety. It just won't be *equivalent*.
