misplaced @trust?

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 5 20:24:00 PST 2015


On Friday, 6 February 2015 at 00:56:09 UTC, Andrei Alexandrescu
wrote:
> On 2/5/15 4:37 PM, Dicebot wrote:
>> On Friday, 6 February 2015 at 00:31:06 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 2/5/15 4:22 PM, Dicebot wrote:
>>>> On Friday, 6 February 2015 at 00:21:45 UTC, Andrei 
>>>> Alexandrescu wrote:
>>>>> On 2/5/15 4:02 PM, Dicebot wrote:
>>>>>> Verifying 50 lines of @trusted with no help from compiler 
>>>>>> at all is
>>>>>> beyond those limits.
>>>>>
>>>>> Do you use @safe at work? -- Andrei
>>>>
>>>> If it is sarcasm, it could have been better.
>>>
>>> It's candid. You're saying you cannot verify safety of a 
>>> 50-lines
>>> function, but I know you are using D1 at work. So I don't see 
>>> how your
>>> claim can be true.
>>
>> You do realize that I was one of reviewers for those Phobos 
>> pull
>> requests you complain about?
>
> The reference was to the fact that you are obviously a 
> competent engineer using an unsafe language, yet claim to be 
> completely hopeless in reviewing a 50-liner that reads data 
> from a file. -- Andrei

I referred to this fact with a comment "it is better to make no
promises than to make one and break it". Simply dealing with
unsafe language is something I got used to - all crashes and
weird think become expected. It is totally different from seeing
a memory corruption with @safe - "hey, you lied to me, it is not
safe!". Because of that amount of responsibility reviewing
@trusted is much higher than reviewing @system. I can do the
latter because I don't pretend review to be perfect. With
@trusted pressure is much harder.

What is worse, as it has been already mentioned, it is not just a
one time effort - careful review necessity taints all code that
gets called from @trusted code. With that much continuous effort
required there feels no point in trying to go for @safe as
opposed to just having @system everywhere and relying on
old-school memory safety techniques.


More information about the Digitalmars-d mailing list