Re: [boost] Boost.GSL?

Subject: Re: [boost] Boost.GSL?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-25 13:39:58

Le 25/09/15 08:47, Nevin Liber a écrit :
> On 24 September 2015 at 16:02, Andrey Semashev <andrey.semashev_at_[hidden]>
> 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