February 05, 2015
On 2/5/15 3:22 PM, Dicebot wrote:
> To put it differently - there is no way I would have ever taken the risk
> merging a 50-line @trusted function, be it Phobos or work project.

Surely you're exaggerating. We're looking at a function that performs system calls and reads into a memory buffer allocated appropriately (and economically). Claiming that that function is safe then enumerating the numerous unsafe and unprovable escape hatches it uses is someone claiming "I'm a virgin - of course save for those six one-night stands I've had."

It's unclear what you're advocating here. I don't think your previous arguments stand scrutiny. One possible new argument might be an analysis on how this:

https://github.com/D-Programming-Language/phobos/blob/accb351b96bb04a6890bb7df018749337e55eccc/std/file.d#L194

is easier to reason about than this:

https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L194


Andrei

February 06, 2015
On Thursday, 5 February 2015 at 23:47:00 UTC, Andrei Alexandrescu wrote:
> On 2/5/15 3:22 PM, Dicebot wrote:
>> To put it differently - there is no way I would have ever taken the risk
>> merging a 50-line @trusted function, be it Phobos or work project.
>
> Surely you're exaggerating.

Not even slightly. I have revoked my Phobos access for a specific reason that I can't do the reviewer job properly with such requirements and would have been forced to ignore all pull requests that tackle @trusted anyway.

> We're looking at a function that performs system calls and reads into a memory buffer allocated appropriately (and economically). Claiming that that function is safe then enumerating the numerous unsafe and unprovable escape hatches it uses is someone claiming "I'm a virgin - of course save for those six one-night stands I've had."

So what? I don't care how justified it is, I simply don't trust my attention span enough do verify that foo() is a virgin. I am not a rock-star programmer and I know my limits. Verifying 50 lines of @trusted with no help from compiler at all is beyond those limits.

When all exceptions to safety are explicitly listed I can review the implementation knowing "ok, this will be safe _unless_ it gets screwed by data coming from those trusted wrappers". And that is big mentality switch that helps to maintain focus.

> It's unclear what you're advocating here. I don't think your previous arguments stand scrutiny. One possible new argument might be an analysis on how this:
>
> https://github.com/D-Programming-Language/phobos/blob/accb351b96bb04a6890bb7df018749337e55eccc/std/file.d#L194
>
> is easier to reason about than this:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L194


It will be a very short analysis considering I am not able to reason about the latter one at all - it simply requires too much of a time investment to me to even consider it.
February 06, 2015
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
February 06, 2015
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.
February 06, 2015
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.

Andrei

February 06, 2015
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?
February 06, 2015
On 2/5/2015 4:02 PM, Dicebot wrote:
> I have revoked my Phobos access for a specific reason that I
> can't do the reviewer job properly with such requirements and would have been
> forced to ignore all pull requests that tackle @trusted anyway.

It's appropriate to recuse yourself from reviewing aspects of code that you disagree with. I do the same. But it seems a little drastic to withdraw from all the rest. There's plenty, plenty more in Phobos.
February 06, 2015
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

February 06, 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.
February 06, 2015
On 2/5/2015 8:24 PM, Dicebot wrote:
> 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.

That is only true if the @trusted code has an unsafe interface. Determining if a function has a safe interface is a far, far smaller and more tractable problem than examining all the code that calls it.