D compiles fast, right? Right??

[H. S. Teoh]

On Wed, Apr 04, 2018 at 08:29:19PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Wednesday, 4 April 2018 at 20:04:04 UTC, Jack Stouffer wrote:
> > On Wednesday, 4 April 2018 at 01:08:48 UTC, Andrei Alexandrescu wrote:
> > > Exactly, which is why I'm insisting this - and not compiler
> > > benchmarking, let alone idle chattaroo in the forums - is where we
> > > need to hit. What we have here, ladies and gentlemen, is a
> > > high-impact preapproved item of great general interest. Shall we
> > > start the auction?
> > 
> > Are you aware of this PR? https://github.com/dlang/dmd/pull/8124
> 
> This is but a layer of paint over the real problem.  Unneeded
> Dependencies. Programming should not be a game of jenga.  Piling
> things on top of other things rarely works out.

Unneeded dependencies is (partly) addressed by this PR, by isolating
user code from the unittests (and by extension, their dependencies) of
external libraries that said user code has no interest in.

True, this does not solve the entire problem, which is that too much of
Phobos is involved in a hairball of inextricable dependencies.  The
situation actually has already improved since 3-4 years ago, when it was
much, much worse.  It's just that we have still some ways to go.

On the flip side, though, why *shouldn't* unittests in a Phobos module
make use of other Phobos modules?  It's one thing to say that Phobos
code proper (i.e., outside of unittests) should be as independent as
possible, and that I agree with, strongly.  But unittests should be free
to import other stuff in order to make testing easier, and also ddoc'd
unittest examples more relevant to the reader.  By separating the import
of a module from the importing of its unittests (which doesn't even make
sense from an API perspective -- why should downstream user code need to
pull in upstream unittests, which are supposed to be used only for
upstream development?), we provide freedom for upstream library authors
to make use of external components in order to test their code, without
penalizing downstream user code with dependencies they don't care about.

I'd say this PR strikes at the heart of this problem, it's not just
papering over the issue.  It's not a full solution, but it's an
important step towards a full solution.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall