Andrei identified a key blocker for D adoption is the incomplete implementation of @safe. I'm working on the compiler end. But Phobos has a lot of code that is pointlessly not @safe, making it frustrating to write @safe code that calls Phobos. Some are listed in Bugzilla, most are not.

So here's what to do:

1. Pick a module, any module, let's say 'std.foo'.

2. Compile it:

    dmd -unittest -main std/foo

and run:

    foo

to verify that the unittests work.

3. Take a look at foo.d and look for a unittest that is not marked @safe.

4. Add @safe to the unittest

5. Do Step 2 on it.

6. If it works, submit a PR with the annotation (well, try to collect a few of these in one module)

7. If it doesn't work, find out where the unsafe code is and fix it, and submit a PR.


I've submitted maybe a dozen PRs against Phobos over the last day from doing this. It's only a start.

Debugging tip:

Templates should almost never be marked @safe or @trusted, as the safety should be inferred. However, to isolate down where the unsafe code actually is, add @safe temporarily to the template declaration. Then, the compiler will tell you which line in the template is unsafe.

On 6/25/2016 3:44 PM, Walter Bright wrote:
> 4. Add @safe to the unittest

A unittest that is deliberately unsafe should be annotated with @system. Meaning that any un-annotated unittest needs corrective action one way or the other.

On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
> On 6/25/2016 3:44 PM, Walter Bright wrote:
>> 4. Add @safe to the unittest
>
> A unittest that is deliberately unsafe should be annotated with @system. Meaning that any un-annotated unittest needs corrective action one way or the other.

So why not declare @safe module-wise, and only add @system annotations where needed?

On Sunday, June 26, 2016 06:29:05 Tourist via Digitalmars-d wrote:
> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
> > On 6/25/2016 3:44 PM, Walter Bright wrote:
> >> 4. Add @safe to the unittest
> >
> > A unittest that is deliberately unsafe should be annotated with @system. Meaning that any un-annotated unittest needs corrective action one way or the other.
>
> So why not declare @safe module-wise, and only add @system annotations where needed?

In general, IMHO, mass applying attributes is a bad idea, because it makes it harder to know which attributes apply where, which is a maintenance problem. However, even worse than that, while there it _is_ possible to apply @safe to the module as a whole and then selectively apply @trusted and @system explicitly, there is no way to turn off all of the @safety attributes so that attribute inference can be used. And other attributes can't be undone at all. So, if you have templates in a module, mass applying attributes is a disaster.

- Jonathan M Davis

On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
> Andrei identified a key blocker for D adoption is the incomplete implementation of @safe. I'm working on the compiler end. But Phobos has a lot of code that is pointlessly not @safe, making it frustrating to write @safe code that calls Phobos. Some are listed in Bugzilla, most are not.
>
> So here's what to do:
>
> 1....

Could we have a wiki page for this call to action? It would be much easier if there is a list of the modules and their current state like: completed or who is working on this module.

In general the call to actions topics disappears too fast in a forum. Maybe it worths to add them to the contributions group in the wiki?

Kind regards
Andre

It would be awesome if you would create that process model in the wiki and at it to your action list http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List

So it does not get lost and people can find it.

On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
> Andrei identified a key blocker for D adoption is the incomplete implementation of @safe. I'm working on the compiler end. But Phobos has a lot of code that is pointlessly not @safe, making it frustrating to write @safe code that calls Phobos. Some are listed in Bugzilla, most are not.
>
> [...]


How hard would it be to add a compiler switch, similar to -vgs that shows every non-safe function? This would not just help out with phobos.

On 6/26/2016 6:13 AM, Robert burner Schadek wrote:
> It would be awesome if you would create that process model in the wiki and at it
> to your action list
> http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List


It's a wiki, feel free to add it.

On Sunday, 26 June 2016 at 22:38:54 UTC, Walter Bright wrote:
> It's a wiki, feel free to add it.

I have to say that reply really makes me angry. I created that list so Andrei and you have an easy to find spot where you can write down tasks so people can work on them. You did not disagree with the list at the time, and didn't disagree so far. I really think it is clear that these are two list that you two are maintaining, how else should anybody know what work is pre-approved and where D is going.

I think I'm not asking too much here, if I ask you to decide if you want to maintain that list or if you want to delete it. The current limbo state is just making things worse.