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.
