On Monday, 25 May 2020 at 12:41:01 UTC, Paul Backus wrote:
> On Monday, 25 May 2020 at 12:30:11 UTC, Zoadian wrote:
>> On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
>>> It is meant to mean that at some point it has been mechanically checked by the compiler.
>>>
>>> Either during current compilation or a prior one.
>>>
>>> Which means it has to be valid on function declarations without bodies so i.e. .di file generation works correctly which is just a generated D file, nothing special syntax of semantics wise.
>>
>> .di files _could_ just use @trusted instead of @safe. but for extern(D) we could at least add it to the name mangling. it's still not 100% safe, but at least you'd have to work hard to get it wrong.
>
> It's been proposed before that @safe and @trusted should have the same mangling, since there's no difference between them from the calling code's perspective.

It may be true (of course modulo meta-programming) that it doesn't make a difference for the calling code, but I personally want have the guarantees that a function that I'm calling is truly @safe (it doesn't contain or call any @trusted code, transitively, nor it calls any @safe code, which access global variables initialized by @system static/module constructors).

In my line work (blockchain smart contracts) some of the ways of how this is typically achieved include:
* having a very minimal smart contract code size
* having either no third-party dependencies or using one or two which are open-source and more importantly verified by multiple teams and having very high reputation
* extensive code auditing by third-party teams. Depending on the circumstances, we may end up paying more for the auditing of the code, than the actual development.

That said, there is no "strong"-@safe today and even if there was, it would account for a tiny subset of all attack vectors that I have to care about (basically all possible logical bugs allowed in type-safe and memory-safe code), but I'm not sure how erasing the difference between @safe and @trusted on the interface level would help.

On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov [ZombineDev] wrote:
>
> It may be true (of course modulo meta-programming) that it doesn't make a difference for the calling code, but I personally want have the guarantees that a function that I'm

doesn't make a difference for the calling code, but personally
I want [to] have the guarantees that a function that I'm

> calling is truly @safe (it doesn't contain or call any @trusted code, transitively, nor it calls any @safe code, which access global variables initialized by @system static/module constructors).

This is very far from a rigorous definition of "strong @safe-ty" - but I hope it's just enough for the casual reader to understand my intention.

> In my line work (blockchain smart contracts) some of the ways of how this is typically achieved include:
> * having a very minimal smart contract code size
> * having either no third-party dependencies or using one or two which are open-source and more importantly verified by multiple teams and having very high reputation
> * extensive code auditing by third-party teams. Depending on the circumstances, we may end up paying more for the auditing of the code, than the actual development.
>
> That said, there is no "strong"-@safe today and even if there

That said, there is no "strong-@safe" [in D] today and even if there

> was, it would account for a tiny subset of all attack vectors that I have to care about (basically all possible logical bugs allowed in type-safe and memory-safe code), but I'm not sure how erasing the difference between @safe and @trusted on the interface level would help.

On Monday, 25 May 2020 at 13:22:36 UTC, Petar Kirov [ZombineDev] wrote:
> On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov [ZombineDev] wrote:
>>
>> It may be true (of course modulo meta-programming) that it doesn't make a difference for the calling code, but I personally want have the guarantees that a function that I'm
>
> doesn't make a difference for the calling code, but personally
> I want [to] have the guarantees that a function that I'm
>
>> calling is truly @safe (it doesn't contain or call any @trusted code, transitively, nor it calls any @safe code, which access global variables initialized by @system static/module constructors).
>
> This is very far from a rigorous definition of "strong @safe-ty" - but I hope it's just enough for the casual reader to understand my intention.

I'm sure this is reasonable for your use-case, but I hope you can recognize that this definition of safety is far too narrow to be suitable for a general-purpose programming language (which D purports to be). Most people would like their @safe code to be able to do I/O, for example, despite the fact that it necessarily involves calling @system code under the hood.

On Monday, 25 May 2020 at 13:43:07 UTC, Paul Backus wrote:
> On Monday, 25 May 2020 at 13:22:36 UTC, Petar Kirov [ZombineDev] wrote:
>> On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov [ZombineDev] wrote:
>>>
>>> It may be true (of course modulo meta-programming) that it doesn't make a difference for the calling code, but I personally want have the guarantees that a function that I'm
>>
>> doesn't make a difference for the calling code, but personally
>> I want [to] have the guarantees that a function that I'm
>>
>>> calling is truly @safe (it doesn't contain or call any @trusted code, transitively, nor it calls any @safe code, which access global variables initialized by @system static/module constructors).
>>
>> This is very far from a rigorous definition of "strong @safe-ty" - but I hope it's just enough for the casual reader to understand my intention.
>
> I'm sure this is reasonable for your use-case, but I hope you can recognize that this definition of safety is far too narrow to be suitable for a general-purpose programming language (which D purports to be). Most people would like their @safe code to be able to do I/O, for example, despite the fact that it necessarily involves calling @system code under the hood.

I don't want to change the definition of @safe in D, but would rather like if D supported @strongSafe, that interested people like me could opt into.
I know that worded like this it may sound like too narrow feature to add to the language (or at least not having favorable complexity/use cases ratio).
So instead, I'd like to have transitive UDAs [1], a feature that has been requested by many, for various use cases ;)

[1]: Basically I want to be able to implement function attributes like @nogc or nothrow in user-space, but that's a long way from now, as first, we need to be able to introspect function bodies.

On Monday, 25 May 2020 at 15:07:19 UTC, Petar Kirov [ZombineDev] wrote:
> I don't want to change the definition of @safe in D, but would rather like if D supported @strongSafe, that interested people like me could opt into.
> I know that worded like this it may sound like too narrow feature to add to the language (or at least not having favorable complexity/use cases ratio).
> So instead, I'd like to have transitive UDAs [1], a feature that has been requested by many, for various use cases ;)
>
> [1]: Basically I want to be able to implement function attributes like @nogc or nothrow in user-space, but that's a long way from now, as first, we need to be able to introspect function bodies.

Sounds to me like a great use-case for the DMD-frontend-as-a-library project.

On Friday, 22 May 2020 at 20:08:37 UTC, Dukc wrote:
> On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote:
>>
>> Sorry, I didn't express myself well. I meant that the user can still mark functions as @system, they just have to do it explicitly.
>
> Hm, DPP might be of help here. Becuse I quess you are going to make sure it'll mark everything `@system`?

My plan is probably to do that, yes. I've been thinking about it and I'll likely need to give users options to opt-in to declaring functions @safe, otherwise none of them every would be with this:

@system {
    #include "header.h"
}

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
> The more I think of Atila's and Walter's responses, the more they are starting to make sense.
>
> [...]

Thank you for the anecdote, especially since it captures the spirit of what I've been trying to convey here.

On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote:
> On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
>> I'd like to emphasize:
>>
>> 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe.
>>
>> 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons.
>>
>> 3. Un-annotated declarations are easily detectable in a code review.
>>
>> [...]
>
> If we were designing a new language from scratch, I would agree 100% with your reasoning.
>
> The problem is that there are un-annotated declarations in existing code that have already been reviewed, committed, and published under the assumption of @system-by-default. Those declarations need to be flagged for re-review in order to avoid introducing silent safety violations to existing D projects.

I share your concerns on this, but disagree on the likelihood of reviews having gone by under the assumption of @system by default. I doubt most people even thought about @safe/@trusted/@system, and that's assuming anyone reviewed the code in the first place.

A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness.

On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
> On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote:
>>
>> If we were designing a new language from scratch, I would agree 100% with your reasoning.
>>
>> The problem is that there are un-annotated declarations in existing code that have already been reviewed, committed, and published under the assumption of @system-by-default. Those declarations need to be flagged for re-review in order to avoid introducing silent safety violations to existing D projects.
>
> I share your concerns on this, but disagree on the likelihood of reviews having gone by under the assumption of @system by default. I doubt most people even thought about @safe/@trusted/@system, and that's assuming anyone reviewed the code in the first place.
>
> A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness.

Walter's claim was that "un-annotated declarations are easily detectable in code review." The intent of my response was simply to point out that for existing D code, the opportunity for such review, and therefore for the detection of such declarations, is already in the past.

In any case, your response does not change my conclusion: the compiler must warn D programmers that their declarations need to be reviewed for compatibility with @safe-by-default. Whether they were reviewed before that or not makes no difference.

On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
> A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness.

Ideally you should be able to blindly mark every function definition with @safe, because the compiler will catch you if you fall. Only if you type @trusted you should need to be careful.