Le 25/09/15 08:47, Nevin Liber a écrit :
On 24 September 2015 at 16:02, Andrey Semashev
wrote: I can see there is a library of different components, some of which are probably useful (again, I didn't take a detailed look). Most of it looks like it could be proposed as an extension of Boost.Utility, but it could be separated into one or multiple libraries.
IMO, they need to be in their own namespace far away from the boost namespace.
Gabriel Dos Reis said in a comment that they expect several implementations of this library. I we want to inter-operate with any static analysis tool yes. We need to put it in the same namespace. The main problem is that there is no specification of this library, so it would be very difficult to have another implementation.
Concrete example: GSL has its own string_view < https://github.com/Microsoft/GSL/blob/master/include/string_view.h>, which doesn't match the interface of std::experimental::string_view. The domains are similar enough that this name will do nothing but cause endless confusion.
I don't think that we need to look now at the current implementation, we need a specification.
Given this is a new project with no obvious historical reason to use the name string_view, I'm a bit wary about such a project that isn't paying attention to what is being standardized. I would suggest that the guidelines recommend the use of std::experimental::string_view/variant, .... instead of their own versions of string_view or variant.,
Being in a separate namespace means one *can* name it the same, but that doesn't mean that one *should*.
Personally I disagree with some of the guidelines, so I would probably
reject it during the review anyway.
Same here. We can not all agree with all the guidelines, even the core guidelines.
Vicente