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

Oh I understand. The notion of calibration comes to mind.

> 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.

I don't see it as bad, but I see what you're saying. Anyhow, it's likely we all grew tired of each other's arguments.

Probably best to stop here. Fresh perspectives would be great. Until then there is no change to @safe/@trusted/@system.


Thanks,

Andrei

On Friday, 6 February 2015 at 06:25:06 UTC, Andrei Alexandrescu wrote:
> On 2/5/15 8:24 PM, Dicebot wrote:
>> 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.
>
> Oh I understand. The notion of calibration comes to mind.
>

I'd like D to provide the following guarantee: If I corrupt my memory using @safe code, the error must be in code marked @trusted / @system, either because the do not provide a @safe interface or because they are buggy.

We'll never provide a stronger guarantee as long as we allow to escape @safe-ty, just like we'll never be able to guarantee that a T is a valid T as long as we allow casts.

I think the guarantee is worth the effort, though.

On 2/6/15 3:26 AM, Tobias Pankrath wrote:
>
> I'd like D to provide the following guarantee: If I corrupt my memory
> using @safe code, the error must be in code marked @trusted / @system,
> either because the do not provide a @safe interface or because they are
> buggy.

That's what we're going for. -- Andrei

On 2/6/2015 8:10 AM, Andrei Alexandrescu wrote:
> On 2/6/15 3:26 AM, Tobias Pankrath wrote:
>> I'd like D to provide the following guarantee: If I corrupt my memory
>> using @safe code, the error must be in code marked @trusted / @system,
>> either because the do not provide a @safe interface or because they are
>> buggy.
>
> That's what we're going for. -- Andrei


Exactly. And it's been that way all along.

On 2015-02-05 22:35, Walter Bright wrote:

> It's no different from:
>
> Q: the compiler gave me a mismatched type error!
> A: put in a cast and it'll compile!

The difference is if you do that the compiler won't disable type checking for the whole function.

-- 
/Jacob Carlborg