Andrey Semashev-2 wrote
Hi,
I propose to extract common_type.hpp (and its implementation and tests) into a sublib within type_traits (e.g. type_traits/common_type).
I would like to know what "sub lib" means in this context. Is it a git submodule? Something that is somehow "embedded" in another module or what? I all you mean is that it has it's own module in our current "flat" list of modules that might be OK. Though it's unclear about what benefit it has. See my other post on this subject. The "modularization" can't be considered independently of the benefit is it mean to provide. Possible benefits might be a) faster builds b) easier maintenance c) smaller distributions of boost subsets d) more clearly defined responsibilities and of course there might be other consequences depending on how modularization is "undertaken" a) slower builds b) harder maintenance c) larger distributions of boost subsets e) less clearly defined responsibilities amongst boost authors. But what i really missing is which benefits we hope to achieve for which group of users. I haven't seen this yet. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Modularization-proposal-tp466... Sent from the Boost - Dev mailing list archive at Nabble.com.