new DIP47: Outlining member functions of aggregates

[H. S. Teoh]

On Mon, Sep 09, 2013 at 02:20:34PM -0700, Andrei Alexandrescu wrote:
> On 9/9/13 12:35 PM, H. S. Teoh wrote:
> >Auto-generation of .di files solves this problem. (Provided we fix the
> >mess that is the current implementation of .di generation, of course.)
> 
> OK, so what's the trouble with .di generation today?
[...]

1) It could be pretty-printed (it currently tries to, but it's not very
pretty).

2) Eponymous templates look ugly. I.e., this:

	template MyClass(T) {
		class MyClass {
			...
		}
	}

   instead of:

   	class MyClass(T) {
		...
	}

3) It loses manual formatting, like turning this:

	writeln("This is a very very long string "~
		"broken across multiple lines");

   into:

	writeln("This is a very very long string "~ "broken across multiple lines");

   which detracts from readability when the expression is very long.
   This also applies to signature contraints, which are just
   concatenated onto an already-over-long function signature.

   A related issue concerns reordering of function qualifiers, e.g., if
   your code looks like this:

   	void func(int a) pure @safe nothrow {
		...
	}

   it gets turned into:

   	pure @safe nothrow void func(int a) {
		...
	}

   which is a bit jarring since when reviewing the .di file you may be
   expecting what you wrote, not what the compiler thinks you should
   have written.

4) It includes template function bodies inline, which means it fails to
   serve as a class-at-a-glance format in that case. It could use the
   declare-first, implement-later approach some have suggested, i.e.:

   	class MyTemplateClass(T) {
		void member();

		...

		void member() { /* implementation here */ }
	}

    instead of the current:

    	class MyTemplateClass(T) {
		void member() { /* implementation here */ }
		...
	}

5) Private templates are included along with public ones: to achieve
   Manu's goal of interface-at-a-glance, private members and private
   templates should be put at the end of the file, rather than in the
   midst of the public symbols. Though this is a minor issue; you could
   just reorder code in the source manually.

There may be a few other points I missed. But all in all, it's not
*quite* ready to serve as an interface-at-a-glance format yet. I didn't
find any inherent limitations, though (except possibly for templated
private members, but those can be largely alleviated by suitable
reordering), so once these issues are addressed, we should be good to
go.


T

-- 
In theory, there is no difference between theory and practice.