@trust is an encapsulation method, not an escape

[Walter Bright via Digitalmars-d]

On 2/5/2015 7:00 PM, Andrei Alexandrescu wrote:
> On 2/5/15 6:52 PM, Walter Bright wrote:
>> On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
>>> (2) I don't think the proposal you sketched at http://goo.gl/JWqafx is
>>> good.
>>
>> The goo link is disabled for violating goo's terms of service, whatever
>> that means.
>>
>> What's the real url?
>
> http://forum.dlang.org/thread/mb070a$1ok1$1@digitalmars.com#post-mailman.6039.1423163991.9932.digitalmars-d:40puremagic.com

Thank you. Essentially, the proposal attaches safe/trusted/system to variables. 
I don't believe this works. Safety/unsafety can often be the emergent 
combination of state of many otherwise 'safe' variables.

In any case, it lacks any demonstration of how it would address the problems in 
std.array. I.e. how could it insure that the code that initializes the array in 
std.array.join() initializes every element? (That loop is in the 'safe' section!)

I don't see how any proposal can work unless it specifies a safe interface to an 
unsafe section of code. (I read a Rust tutorial that rather bluntly pointed this 
out as well.)