20 October 2015

Should GSL string_view should be string_ref instead

(Another one for C++ programmers)

Time for some bikeshedding.

It looks to me like GSL string_view and the library fundamentals TS (hereafter LFTS) string_view have different goals. Also, I have heard it said that the “_view” in LFTS string_view was meant to emphasis that it was read-only.

Perhaps GSL string_view should be called string_ref to distinguish it from LFTS string_view and because it isn’t strictly a “view”?

LFTS string_view’s goals are to be a (as much as possible) drop-in replacement for “const std::string&” without the memory allocation and copying that it sometimes requires. GSL string_view’s goals, however, are safety and being able to replace any use of a raw char array as a function parameter. These differences manifest in (at least) two ways. First, LFTS does not allow modification of the underlying data while GSL string_view does. (Although a const GSL string_view can be used.) Second, LFTS string_view copies all the const member functions of std::string while GSL string_view—just an alias for GSL’s array_view—prefers free functions for string-specific operations.

It doesn’t look like it will be easy to serve all of those goals without getting ugly. As much as it would be a shame to have two versions of somewhat similar concepts.

(I’m not as familiar with N3841 array_view yet, so I’m unsure if there is an analogous issue for array_view.)

Update (6 November 2015): Good news. In the wake of the October 2015 meeting in Kona, GSL’s array_view and string_view will be renamed span and string_span.

No comments: