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
