On Thu, Feb 05, 2015 at 06:56:02PM +0000, Zach the Mystic via Digitalmars-d wrote: > On Thursday, 5 February 2015 at 18:21:40 UTC, Steven Schveighoffer wrote: > >On 2/5/15 1:12 PM, Zach the Mystic wrote: > > > >> > >>Hey I like the creativity you're showing. Just to give people a > >>concrete idea, you might show some sample code and illustrate how > >>things work. It sure helps when I'm trying to think about things. > > > >So for example: > > > >@safe int *foo() > >{ > > int *x; > > int *y; > > int z; > > x = new int; // ok > > //y = &z; // not OK > > @trusted y = &z; // OK, but now y is marked as @trusted > > // return y; // not OK, cannot return @trusted pointer in @safe > >function > > return cast(@safe)y; // ok, we are overriding the compiler. > > // and of course return x; would be ok > >} > > > >-Steve > > `cast(@safe)`...interesting. It's the most fine-tuned way of adding > safety, whereas @trusting a whole function is the most blunt way. > > I've been hatching a scheme for reference safety in my head which would > automatically track `@trusted y = &z;` above, marking `y` with > "scopedepth(1)", which would be unreturnable in @safe code. > > I can anticipate the objection that giving people too much power will > encourage them to abuse it... but then again, if that were true, who > let them mark the whole function `@trusted` to begin with? Your > proposal really pinpoints the actual code which needs to be worked on. > > You're basically moving the unit of safety from the *function* to the > *pointer*, which makes sense to me, since only a pointer can really be > unsafe.
I mostly like this idea, except that foo() should not be marked @safe. It should be marked @trusted because it still needs review, but the meaning of @trusted should be changed so that it still enforces @safe-ty, except that now @trusted variables are permitted. Or rather, I would call them @system variables -- they *cannot* be trusted, and must be manually verified. @safe code should not allow any @system variables or any cast(@safe) operations, period. Otherwise, anybody can wrap unsafe operations inside their @safe function and still clothe it with the sheep's clothing of @safe, and @safe becomes a meaningless annotation. In short, my proposal is: - @safe should continue being @safe -- no (potentially) unsafe operations are allowed, period. Rationale: allowing @system variables in @safe code makes the function non-verifiable mechanically. This completely breaks the whole point of @safe. - Change the meaning of @trusted (as applied to a function) to require @safe inside the function body, but in addition permit @system variables and cast(@safe). Rationale: the function cannot be verified mechanically to be safe, therefore it cannot be marked @safe. It must be marked @trusted to draw attention to the fact that manual review is required. However, this does not constitute license to perform arbitrary @system operations. Instead, any @system code/variable inside the @trusted function must be explicitly marked as such, to indicate that these items require special attention during review. Everything else must still conform to @safe requirements. - Introduce @system variables for holding tainted values that the compiler cannot guarantee the safety of, as well as cast(@safe), as described in Steven's post. These constructs are only permitted inside @trusted functions. They are prohibited in @safe code, and are no-ops in @system code. Rationale: to reduce the maintainability problem, @trusted functions should not allow @system code by default. Rather, the scope of @system code/data inside a @trusted function should be restricted by requiring explicit marking. The compiler then helps the verification process by ensuring that anything not explicitly marked is still @safe. T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum