There are quite a few things in Phobos which can be improved without much in-depth knowledge.
As these things get often forgotten and lost in the abyss, I started a few GitHub projects:

- dip1000
- All high-level code should be usable in @safe
- Every Phobos symbol should be properly documented
- Undocumented symbols shouldn't be public
- Every assert should have a message
- Every public symbol should have an example

And primed them with the current blacklists:

https://github.com/dlang/phobos/projects


Note that for all theses checks we have compiler checks or other blacklists to avoid regressions, so gradual improvement is easily possible.


What the heck are GitHub projects?
----------------------------------

Kanban-style board that allow to track the progress of a specific project.
They were successfully used at dmd:

https://github.com/dlang/dmd/projects

It would work a bit better if we used GH issues as they are a couple of handy automations built-in, but well that's an entirely topic.

Why are you posting this here?
------------------------------

Simple: if someone is looking out for a way to help, these projects should provide a simple start.
Also there's quite some interest in the first two (DIP1000, more @safe-ty), so tracking the progress at a central place should give them a better visibility and allows everyone to see the progress or pitch in.

On Monday, 29 January 2018 at 17:51:40 UTC, Seb wrote:

> - All high-level code should be usable in @safe

This is not currently possible with functions that take a delegate parameter, including opApply. (without sacrificing genericity)

A DIP could be made so that the function infers it's attributes from a delegate argument, but that's so much added complexity that it's debatable whether it would be worth it.

On Tue, Jan 30, 2018 at 08:08:14AM +0000, Dukc via Digitalmars-d wrote:
> On Monday, 29 January 2018 at 17:51:40 UTC, Seb wrote:
> 
> > - All high-level code should be usable in @safe
> 
> This is not currently possible with functions that take a delegate parameter, including opApply. (without sacrificing genericity)
> 
> A DIP could be made so that the function infers it's attributes from a delegate argument, but that's so much added complexity that it's debatable whether it would be worth it.
[...]

You could templatize opApply so that the compiler applies automatic attribute inference:

	struct S {
		int opApply(Dg)(scope Dg dg)
		{
			foreach (i; 0 .. 5)
			{
				auto ret = dg(i);
				if (ret) return ret;
			}
			return 0;
		}
	}
	void systemFunc() @system
	{
		void* p;
		S s;
		foreach (int i; s) {
			p++;
		}
	}
	void safeFunc() @safe
	{
		int x;
		S s;
		foreach (int i; s) {
			x++;
		}
	}

Unfortunately, this also means that you can no longer have the compiler deduce the type of the loop iteration variable (the 'int' in the foreach loops is now required, since the compiler can't infer it from the generic template parameter Dg).  Not to mention the template bloat from each combination of delegate attributes.

What we need here is the analogue of 'inout' for function attributes. But given the track record of inout, I'm not sure we want to have another such hack in the language...


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce