On Thu, 05 Nov 2009 15:20:34 -0500, Andrei Alexandrescu
<[email protected]> wrote:
Steven Schveighoffer wrote:
On Thu, 05 Nov 2009 14:57:48 -0500, Michel Fortin
<[email protected]> wrote:
On 2009-11-05 13:33:09 -0500, Walter Bright
<[email protected]> said:
Safety seems more and more to be a characteristic of a function,
rather than a module or command line switch. To that end, I propose
two new attributes:
@safe
@trusted
Looks like a good proposal.
That said, since most functions are probably going to be safe,
wouldn't it be better to remove @safe and replace it by its
counterpart: an @unsafe attribute? This would make things safe by
default, which is undoubtedly safer, and avoid the unnecessary clutter
of @safe annotations everywhere.
If unsafe means you cannot pass pointers to local variables, then half
of tango (and other performance oriented libs which use stack
allocation as much as possible) will fail to compile.
While I agree with your point, quick question: could you use ref
parameters instead? Ref will be usable in SafeD.
Most of the usages are like this:
ubyte[1024] buffer;
functionThatNeedsBufferSpace(buffer);
where functionThatNeedsBufferSpace takes a ubyte[], thereby taking an
address of the local data.
So it's not explicit address taking, but it's the same thing under the
hood. There always exists the potential for the stack reference to escape.
Similar case is scope classes (which are sometimes used to allocate a
temporary class for performance in tango). I can't see scope classes
being allowed if you can't take addresses of local variables.
I'm not saying that safed needs to allow these kinds of things somehow
(thereby employing escape analysis), but it might be too restrictive for
performance-oriented libs/apps. I think it's acceptable that tango
eventually gets marked with @trusted, but by making @safe the default, you
will immediately make many D1 projects not compile without significant
effort, which might drive away developers from D2, or else make people
automatically mark all files as @trusted without thinking about it. By
defaulting to untrusted and unsafe, you allow people to incrementally add
@safe and @trusted tags where they are appropriate and correct.
-Steve
