On 12/05/14 20:58, Francesco Cattoglio wrote:
Error messages!
If your code is not compiled, you can't know whether it is valid or not.
I must say that since we have unittests, this is somewhat less relevant,
but still...
One nice thing would be stripping the executable of unneeded code.
One tri
You can write a tool, which will construct an amalgamation build
of your code.
On Monday, 12 May 2014 at 08:37:43 UTC, JR wrote:
What am I missing?
Error messages!
If your code is not compiled, you can't know whether it is valid
or not.
I must say that since we have unittests, this is somewhat less
relevant, but still...
One nice thing would be stripping the executab
On Monday, 12 May 2014 at 09:16:53 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Well, that would be a lot of extraneous files, which would be
very messy IMHO.
It also makes it much harder to share private functionality,
because
everything is scattered across modules - you'd be force to u
On 5/12/14, 5:37 AM, JR wrote:
Given that...
1. importing a module makes it compile the entirety of it, as well as
whatever it may be importing in turn
2. templates are only compiled if instantiated
3. the new package.d functionality
...is there a reason *not* to make every single function/stru
On Mon, 12 May 2014 08:37:42 +
JR via Digitalmars-d-learn wrote:
> Given that...
>
> 1. importing a module makes it compile the entirety of it, as
> well as whatever it may be importing in turn
> 2. templates are only compiled if instantiated
> 3. the new package.d functionality
>
> ...is the
Given that...
1. importing a module makes it compile the entirety of it, as
well as whatever it may be importing in turn
2. templates are only compiled if instantiated
3. the new package.d functionality
...is there a reason *not* to make every single
function/struct/class separate submodules