1. How can I separate class methods from the declaration block? And how can I implement them in a separate module?

module frame;
class Test
{
public:
	int x;
	this();
}

Test.this()
{
	x = 34;
} // does not work

In this scenario I would like to take the constructor to a different module called "construct".


2. For practice, I want to implement a few containers in native D using DUB. The project aims to create libraries for different data structures. I'm thinking that I should make packages for different containers and have them under source/. For example, source/forward_list, source/queue, source/set etc.

Would you like to suggest me a good project structures for this? Imagine I am making a package called forward_list. Under the directory forward_list/, I have modules.d that imports dedicated modules for useful methods like push_back, insert_after, front, sort, merge etc. Is it an acceptable practice to declare classes in package.d? So it becomes

//module package.d;
class forward_list
{
public:
	int x;
        merge();

        this(){}
        this(int x){ this.x = x; }
}

//module merge.d;
import package.d

forward_list.merge(Object o){
        //..
}

On Thursday, 7 December 2017 at 02:32:03 UTC, helxi wrote:
> 1. How can I separate class methods from the declaration block? And how can I implement them in a separate module?

module a;
class Test
{
  import b;
  mixin TestMethodImpl!();
}

module b;
template TestMethodImpl()
{
  void foo();
}

But this is abnormal for D. We almost invariably put function bodies inside declarations.

What's your goal with separating the declaration from the implementation?

If you want people to be *unable* to read method bodies, you can generate *.di files that only contain declarations. `dmd --help | grep -i header` or so -- though that keeps in templates and functions that are candidates for inlining.

If you want to make it easy for someone to look at the API without wading through function declarations, use ddox to generate HTML documentation.

> Imagine I am making a package called forward_list. Under the directory forward_list/, I have modules.d that imports dedicated modules for useful methods like push_back, insert_after, front, sort, merge etc. Is it an acceptable practice to declare classes in package.d?

That would be abnormal.

You can look at the layout of std.container by way of comparison -- one module per container type, one for miscellaneous utilities, and only documentation in package.d.