On Tuesday, 1 September 2015 at 17:35:23 UTC, Jonathan M Davis
wrote:
On Tuesday, 1 September 2015 at 15:10:28 UTC, Dominikus Dittes
Scherkl wrote:
On Tuesday, 1 September 2015 at 12:55:11 UTC, Benjamin Thaut
wrote:
While your proposal sounds interresting to start with I don't
like some of the implications:
1) You force people to write unittest. If people don't write
a export unittest block their templates won't work across
shared library boundaries.
Not writing unittests is a bad idea anyway.
Much more so if you want to ship your code as library!
2) A template in D might get __very__ complex. To make sure
that each and every function needed is actually exported your
unittests would need to have 100% coverage. Looking at some
of the template code in phobos this won't be any more fun
than manually putting export in front of every required
function.
Oh yes, it's much more fun, because you get something very
valueable in return: 100% coverage!
The more complex the template gets, the more valueable such a
unittest becomes.
Especially in phobos I pretty much expect such unittests to
already exist. What a shame if not so!
Yeah, any arguments which are basically saying that you need a
feature because you shouldn't have to have 100% code coverage
is going to fall flat with Walter and Andrei. All code that is
released should have 100% test coverage unless it has a really
good reason why it can't, and it's egg on the face of the
developer who releases the code without that - and no, we don't
do a good enough job of that with Phobos, and that _is_ egg on
our face. We have good code coverage, but we often don't have
100%, and when we don't, we miss bugs. That test coverage needs
to be there, and without it, it's far too easy to release stuff
that mostly works but falls apart in the corner cases.
So, if there's a feature that can be added which solves the
export problems that dicebot is talking about here, but it
requires that you unit test your code for it to catch
everything, then so be it. I really don't see that as an issue.
If it can be done in a simple way that doesn't require unit
testing, then fine, but all of that code should be fully unit
tested anyway, so arguments based on the premise that you
shouldn't need to have full unit test coverage aren't going to
convince anyone - especially not the folks who would approve
the new feature.
- Jonathan M Davis
No. That is very short sighted.
A ton of code is not unitestable. GUI as a starter. Random number
generator. Very rare events handling outside the control of the
program. Concurent code. Etc...
