Possible solution for export : `unittest export`?

[deadalnix via Digitalmars-d]

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...