Re: URL Review

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2022-08-22 16:04:28

Vinnie Falco wrote:
> On Sun, Aug 21, 2022 at 6:21 AM Phil Endecott via Boost
> <boost_at_[hidden]> 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.