Possible solution for export : `unittest export`?

[deadalnix via Digitalmars-d]

On Wednesday, 2 September 2015 at 00:00:55 UTC, Dicebot wrote:
> On Tuesday, 1 September 2015 at 18:11:02 UTC, deadalnix wrote:
>> Ok I get it. I'm not sure that is the right way forward.
>
> I am not sure either but we have lack of ideas in this domain, 
> brainstorming :)
>
>> The same problem arrise for devirtualization and the solution 
>> does not cover it. That is a problem.
>
> Can you expand on this problem a bit more please? I know about 
> issue of not knowing if some method is eventually overridden 
> but that seems to be fixed with export within single 
> compilation step (i.e. small static library). Do you mean 
> something different?
>

That is pretty much the same problem. You'd like to devirtualize 
method that are not marked final but that are in fact never 
overriden. The fact that the compiler is blind when it comes to 
template means that the compiler have a much harder time to know 
what method are or can be overriden.

>> First I'd like to have more compiler checks on template 
>> bodies. Andrei and Walter are not super happy with it, but 
>> deep down I do think their point is more the result of the 
>> clash with the C++ community over static if vs concept than 
>> based on any technical merit (the whole thing is a false 
>> dichotomy to start with so the clash and its results are 
>> nonsensical).
>
> I don't think it is even practical to try pushing in that 
> direction at this point even if I generally agree with 
> statement. Unless you are going to propose to restrict what 
> exported templates can do (0 chance to fly) there still needs 
> to be _some_ solution that works if existing semantics.
>

Yes I know that this isn't going to fly with Andrei/Walter. Sad 
as it is pretty much the only solution that solve the problem at 
its root, rather than proposing a work around some aspect of the 
problem.

>> Second, it is most likely a good idea to issue some kind of 
>> error when export within template code calls non export code. 
>> That most likely needs to be an error. The error would show up 
>> with descent test coverage even without the special feature.
>
> Isn't it essentially the same thing I propose, but simply based 
> on convention instead of dedicated feature? It is probably fine 
> but to be honest I think it really does matter to have clear 
> indicator "this is how things are supposed to be done" in this 
> domain. Simply because applying idioms from other languages 
> will be natural course of actions and is unlikely it work in 
> practice.

My understanding was that you got an error if you don't 
instanciate the template in the export unitest block. But maybe 
I'm wrong.

I'd be in support of an export unitest block that behaves as an 
export function, and so would give error if it uses non exported 
symbols.