On Tuesday, 14 October 2014 at 17:59:43 UTC, Brad Roberts via
Digitalmars-d wrote:
On 10/14/2014 3:49 AM, monarch_dodra via Digitalmars-d wrote:
You say I'm focused on impl, but @safe *is* an implementation
certification.
I'm not derailing the thread or talking about process. If
Array can't be
certified memory safe, then it can't be marked as @safe.
That's really
all there is to it.
Sorry, the request to not derail was for future posts to the
thread, not a reaction to your comment. I was/am worried that
the "more and more code being created" comment would spiral the
discussion sideways.
Your response wasn't making any statements of what should
happen but rather why it can't based on the current state.
Useful, but still irrelevant to the Should question. Unless
you were saying that it shouldn't become usable due to that
part of the api. To that I'd respond that your thinking is too
narrow in scope or too black and white.
As to the rest, once we decide if Array should be usable in the
@safe subset of the language, then we can start to make choices
about how to achieve that. Some obvious choices:
1) remove the parts that aren't (unlikely to be a good choice)
2) partition the api into parts that are and parts that aren't
(only some parts get the @safe attribute, maybe some gets
@trusted)
3) improve the implementation of @safe to cover all the parts
that can't right now (likely to result in significant delay
before any useful progress is made)
4) force the parts that aren't anyway (probably violates the
basic precepts of @safety but including for the sake of
completeness)
5) ?
6) some combination of the above
My personal thinking is that #2 is the way to go in the short
term as long as a reasonably large subset of the functionality
can be made usable (right now we can't even construct one).
With a likely very strategic sprinkling of @trusted where
absolutely necessary. As #3 progresses on it's own merits, the
set that falls into #2 might expand.
I'm on vacation on a phone, so I'll be brief for now.
I replied what I said because I felt some arguments were leading
to: let's make it trusted and worry about implementation layer.
I'la ignore the comment that my vision is narrow and discuss
improvement possibilities.
The issue witH safe/unsafe split is that the functions themselves
aren't actually unsafe, but rather their vombination: deletion is
only unsafe *if* an escape has occurred.
The funny thing is that Array used to be sealed (specifically to
avoid escapes) abd could have been safe. I unsealed it with
Andrei because sealed containers come with their own problems.
To the topic at hand though, I don't think safety should dictate
our implementations. In particular, dmd improvements can and will
mean that something unsafe can become safe later.
The real question here is when will we implement the long
promised scope?
