Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Stephen Kelly (hello_at_[hidden])
Date: 2015-02-03 16:02:44
Robert Ramey wrote:
> Stephen Kelly-2 wrote
>> Robert Ramey wrote:
>>> And my proposal for the "bridge" module (maybe better called "forward"
>>> module is just that - a proposal. I would like time to think about that
>>> some more - a hear what other's have to say as well.
>> * Educate yourself about C++17/Clang modules
> I confess that I haven't seen this in any way related to C++17. I would
> certainly be skeptical of anyone spending any time on something as
> as a future C++ standard before it's finalized.
That's no reason not to educate yourself on it, and it's no reason not to
try the clang implementation.
>> * Determine how C++17/Clang modules relate to modular boost releases.
> Since you seem to have some information and/or thoughts about this why
> not save us all a lot of time and just post them here yourself?
C++17/Clang modules are selections of headers grouped together as a self-
contained unit. The unit can have external dependencies. Cycles are bad.
What way would boost headers be grouped together to make use of that?
>> * Determine whether forwarding headers fit into the very real scenario of
>> world where C++17/Clang modules are pervasive.
> I don't see C++17/Clang modules (whatever they might be) pervasive
> in the current real world.
Insisting on not having foresight isn't as good a thing as you think it is.
> As far as I can tell, my proposal for "bridging headers" is the only
> specific one suggested so far.
Erm, no. You pre-rejected any proposal based on splitting anything sensible
out of the serialization repo. As the maintainer, you're the only one who
gets to decide. Yay Boost!
There's no reason to discuss anything which is pre-rejected.
Does your proposal break the cycle which serialization participates in?
If it doesn't, then my comment on your proposal is: choose a solution which
solves the cycle. If it does, please point that out.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk