Re: [boost] URL Review

Vinnie Falco wrote:

On Sun, Aug 21, 2022 at 6:21 AM Phil Endecott via Boost wrote:

...

In previous email discussions a few months ago I complained about the dangerous use of non-owning view types in the library interface,

Yes but... this is how it is. The expectation for this library (and indeed, all my libraries past, present, and future) is that users have a grasp of C++ and are aware of the lifetime rules for both references, and types which have the semantics of references.

There's an important difference between "references" and "types which have the semantics of references", when auto is used: std::string f1(); std::string& f2(); std::string_view f3(); auto r1 = f1(); // r1 is a string, OK. auto r2 = f2(); // r2 is a string, not a string&, so it's safe. auto& r2a = f2(); // r2a is a string&, but the user knows that because they wrote a &. auto r3 = f3(); // r3 is a string_view, danger!

That's the price of admission for the type-erasure and zero-cost abstraction.

I feel that maybe what I'm saying is not getting through: *I am not insisting that you remove these dangerous functions. You are welcome to keep them for those users who feel that they need the benefits that they offer. I would just like you to *also* offer safe-to-use functions, and to give the safe functions more concise names than the dangerous functions (and mention them first in the docs).*

Yes well, we considered that design and concluded that it wasn't practical. The library has multiple value types for URLs, which one should it return?

One of the safe ones. I'd suggest one that uses a std::string to store the URL.

A URL is literally a string which meets the prescribed syntactical requirements of RFC3986. If I receive an HTTP GET request like this:

GET /index.htm HTTP/1.1\r\n

you think that the library should not let the user parse the substring and return a view to the URL? And instead it should allocate memory, all to protect beginners?

No, I'm NOT SAYING THAT IT SHOULD NOT LET THE USER DO THAT, I'm saying that a user who wants to do that should have to do a bit more typing to make it clear to the next person who reads their code that they are using the unsafe view-returning function. It's also worth noting that a URL value-type using a std::string would do no allocations anyway in this case, since "/index.htm" easily fits into the string's SBO storage.

std::string_view is C++17, are we saying now that Boost libraries should avoid some C++ features to appease beginners?

A good API should use std::string_view only for parameters, and possibly for getter methods.

...

In the past I have had situations where it was necessary to specify the case for hex letters in %-encoding; please consider adding this to pct_encode_opts.

Well percent-encoded escapes always use hexadecimal so I'm not sure what you're asking for here.

I'm asking for an option to select either upper case or lower case letters in the hex encodings, i.e. %2D or %2d.

I remember I was at CppCon, I think it was 2018 and I was at some sort of official dinner - probably the speaker's dinner. I got sat next to this loudmouth who at one point starting going off on string_view and how bad it was, how dangerous it was, all the problems it caused in the jillion-line codebase at his job, and how it never should have been added to the standard. He did make some valid points of course but I couldn't shake the feeling that perhaps a programming language other than C++ would suit him better. That person was Nicolai Josuttis.

Yeah, well the last time I had lunch with Bjarne Stroustrup we talked a lot about how to make C++ a language that you could actually teach to students. This was around 2003, and he had just started teaching at Texas A&M at the time.

If we start thinking that users need to be coddled, have the useful but sharp edges filed down, pointy ends blunted, and so forth

*I DON'T WANT THE POINTY ENDS FILED DOWN, I JUST WANT THEM TO HAVE DANGER SIGNS ON THEM AND FOR THE TOOL TO ALSO BE USEABLE IN A SAFE WAY.*

- I feel like we will end up with Rust. For that you can probably just save all the work and start using Rust sooner rather than later.

Two of the C++Now videos that I've watched are Dave Abrahams on value semantics in Swift and Val, and David Sankel on "Rust features that I want in C++". Quote from the Swift talk: "C++ does have mutable value semantics, in fact it's the default, it's just the no-one uses it." It would be a disaster for C++ if it were to become only the language to use if Rust or Swift or D or whatever doesn't do what you want. C++ needs to learn from those languages. In particular, Dave Sankel's talk has a lot about inclusiveness in Rust. Do please view it. Regards, Phil.