• Seb (32/32) Jan 29 2018 There are quite a few things in Phobos which can be improved
• Dukc (7/8) Jan 30 2018 This is not currently possible with functions that take a
• H. S. Teoh (42/52) Jan 30 2018 [...]

Seb <seb wilzba.ch> writes:

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.

Dukc <ajieskola gmail.com> writes:

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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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