On 3/3/15 9:28 AM, Kagamin wrote:
> If one wants to prevent a leak, then counter can be wrapped
> ---
> struct Unsafe(T)
> {
>     private T _payload;
>     T payload() @system { return _payload; }
>     alias payload this;
> }
> ---
> And somehow disallow Unsafe template in safe function signatures, then
> having
> Unsafe!(int*) _counter;
> would be ok?

This is a pretty good idea actually. It's not foolproof (you still have to opt-in to this, the compiler doesn't force it), but it gives you a tool to ensure people aren't using it in an unsafe way without having to double-check every usage. I like it.

-Steve

Being a safety measure, it becomes trusted code's responsibility to provide this safety. BTW it also needs @system postblit; meh, I hope it's enough to make untouchable.

Unsafe!(int*)* _c;

class A
{
  Unsafe!(int*) _counter;
  void escape() @safe { _c = &_counter; }
}

Not sure if it's legal. It should be really untouchable.

On Wednesday, 25 February 2015 at 06:48:17 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 24 February 2015 at 22:49:17 UTC, w0rp wrote:
>> In general, @trusted means "I have proven myself that this code is actually safe, eeven though it uses unsafe features." The compiler has to be pessimistic and assume that everything which can be used unsafely will be used unsafely. @trusted, as it is used here, is used to say, "I assure you I have used this in a safe manner."
>
> From http://dlang.org/function.html#trusted-functions :
>
> «Trusted functions are guaranteed by the programmer to not exhibit any undefined behavior if called by a safe function.»
>
> I take this to mean that anything that is wrapped up in @trusted should not violate memory safety when in injected into any arbitrary context marked as @safe.

The key phrase is "guaranteed by the programmer." Which means that the programmer, not the compiler, is providing a guarantee that calling a @trusted function will not violate memory safety. If the programmer cannot make that guarantee, the function should be marked as @system instead. It's a mechanism which allows humans to achieve something the compiler isn't capable of achieving, at least at this point in time.

Much in the same way that a compiler cannot prove in general that programs will terminate, it can be very difficult for a compiler to prove that your program will not violate memory safety when the language is capable of calling into C code, etc. If you don't have an annotation like @trusted, the amount of code which could be run from @safe functions would be very small indeed.

On Tuesday, 3 March 2015 at 20:56:50 UTC, w0rp wrote:
> The key phrase is "guaranteed by the programmer." Which means that the programmer, not the compiler, is providing a guarantee that calling a @trusted function will not violate memory safety. If the programmer cannot make that guarantee, the function should be marked as @system instead. It's a mechanism which allows humans to achieve something the compiler isn't capable of achieving, at least at this point in time.

Yes, but in that case it should not be OK to wrap up "free(obj)" as @trusted, since it cannot be called safely from @safe code (as in any constellation of @safe code). So either the wording of the spec has to change or this practice goes against the spec.