[Idea] std::string_view and std::string should inherit from the same base class

[omer...@gmail.com]

Consider the following use case:
I have a std::map<std::string, std::string> that sometimes contains strings consumed from C APIs.
They are owned by the C API that I consumed them from.
Other times, I have strings that are consumed from C++ APIs and I can either move them or reference them in some way.
The strings consumed by the C API are copied into std::string because a std::string owns the data. This is wasteful.
We can use std::variant<std::string, std::string_view> to hold both string types but that makes the code far more complex than it should and occasionally still requires copying when other APIs require you to provide an std::string.
string_view and string has almost the same interface (sans c_str() and data() which IMO should be unified). It makes some sense to allow them to be interchangeable.

In OSQuery we use Thrift to communicate with extensions.
Thrift has hardcoded the string type it generates for C++. Even if we did use std::variant<std::string, std::string_view> for RowData we'd still have to copy some of the string_views from Row into ExtensionPluginResponse which is generated to be of type std::map<std::string, std::string>.

If we had a base class for all common string-like data types we could make that requirement less specific by changing the string type in Thrift to be the base class of all strings and less memory copying would be involved when it is not necessary.
I'm sure that are ton of additional use cases where this applies.

Are there any technical reasons why string_view and string don't share the same base class?
Why the difference in APIs between c_str() and data() exists?

[Mathias Gaunard]

On 30 Aug 2017 8:06 am, <omer...@gmail.com> wrote:

Consider the following use case:
I have a std::map<std::string, std::string> that sometimes contains strings consumed from C APIs.
They are owned by the C API that I consumed them from.
Other times, I have strings that are consumed from C++ APIs and I can either move them or reference them in some way.
The strings consumed by the C API are copied into std::string because a std::string owns the data. This is wasteful.
We can use std::variant<std::string, std::string_view> to hold both string types but that makes the code far more complex than it should and occasionally still requires copying when other APIs require you to provide an std::string.

Just use string_view. I don't understand why you want string.

string_view and string has almost the same interface (sans c_str() and data() which IMO should be unified). It makes some sense to allow them to be interchangeable.

c_str() is null-terminated.

If we had a base class for all common string-like data types we could make that requirement less specific by changing the string type in Thrift to be the base class of all strings and less memory copying would be involved when it is not necessary.
I'm sure that are ton of additional use cases where this applies.

I don't understand how that would help at all.

[Thiago Macieira]

On Wednesday, 30 August 2017 00:06:15 PDT omer...@gmail.com wrote:
> I have a std::map<std::string, std::string> that sometimes contains strings
> consumed from C APIs.

Your suggestion would not directly solve your problem, since your std::map
would be of that base type, not of std::string. So it would not own the data
and would not free it when it went out of scope. You need at the very least an
indirection by way of a pointer, so that the concrete object could be
std::string.

But your idea is not without merit. I did explore the possibility of making
QString and QStringView related classes (in fact, QStringView be QString's
base class) and I expect this to be a topic of discussion between now and the
time we release Qt 6. There are arguments in favour of it, such as a
duplicated API for many of the access functions, but also quite a few
arguments against it (functions that return copies, accidental overloading,
etc.)

So your proposal is highly unlikely. At least, you need a very strong paper
explaining all the details.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Ross Smith]

On 2017-08-30 19:41, Mathias Gaunard wrote:
> On 30 Aug 2017 8:06 am, <omer...@gmail.com

> <mailto:omer...@gmail.com>> wrote:
>
> string_view and string has almost the same interface (sans c_str()
> and data() which IMO should be unified). It makes some sense to
> allow them to be interchangeable.
>
> c_str() is null-terminated.

That was true in C++98, but as of C++11, strings are now always null
terminated, and data() and c_str() are synonyms (or were until a
non-const overload of data() was added in C++17).

Ross Smith

[Ville Voutilainen]

Correct, but a string_view is not necessarily nul-terminated.

[Nevin Liber]

On Wed, Aug 30, 2017 at 2:06 AM, <omer...@gmail.com> wrote:

Consider the following use case:
I have a std::map<std::string, std::string> that sometimes contains strings consumed from C APIs.
They are owned by the C API that I consumed them from.
Other times, I have strings that are consumed from C++ APIs and I can either move them or reference them in some way.
The strings consumed by the C API are copied into std::string because a std::string owns the data. This is wasteful.

But even if they come from the C API, you still need some way to tell that API when you are done using that string (or a group of strings, depending on the API).

 

We can use std::variant<std::string, std::string_view> to hold both string types

Your variant doesn't solve the C API ownership problem.

 

occasionally still requires copying when other APIs require you to provide an std::string.

Your variant doesn't solve the problem if other APIs require a std::string.

 

string_view and string has almost the same interface (sans c_str() and data() which IMO should be unified). It makes some sense to allow them to be interchangeable.

This doesn't solve either the C API ownership problem or the problem of other APIs requiring a std::string.

 

If we had a base class for all common string-like data types we could make that requirement less specific by changing the string type in Thrift to be the base class of all strings and less memory copying would be involved when it is not necessary.
I'm sure that are ton of additional use cases where this applies.

I don't see how a common base class addresses any of the problems you brought up, especially considering C APIs generally want 0-terminated strings w/o embedded 0s.

 

Are there any technical reasons why string_view and string don't share the same base class?

Because std::string (a) owns the space and (b) can guarantee the string is 0-terminated when necessary.  string_view does neither of those, and it cannot provide (b) without (a).

 

Why the difference in APIs between c_str() and data() exists?

They (well, the const versions) were different in C++98, in that c_str() guaranteed a 0-terminated string while data() did not.  As of C++11 they both return a 0-terminated string.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[Patrice Roy]

@Ville : would that be a problem in this case, since the source is known to be a null-terminated C string?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Thiago Macieira]

On Saturday, 2 September 2017 08:39:05 PDT Patrice Roy wrote:
> @Ville : would that be a problem in this case, since the source is known to
> be a null-terminated C string?

But you can't know that from the point where std::string_view is used. That's
why it doesn't have a .c_str() member: you can't use it as a C string.

[Patrice Roy]

I know; I was referring to the original use-case specifically, no more.

[Paul "TBBle" Hampson]

On Sunday, 3 September 2017 01:52:43 UTC+10, Thiago Macieira wrote:

On Saturday, 2 September 2017 08:39:05 PDT Patrice Roy wrote:
> @Ville : would that be a problem in this case, since the source is known to
> be a null-terminated C string?

But you can't know that from the point where std::string_view is used. That's
why it doesn't have a .c_str() member: you can't use it as a C string.

Perhaps what's lacking is a zstring_view? string_view with null-terminated c_str(), but none of the subscripting magic

It's not a great type (it doesn't control its own invariant, since you might modify the buffer underneath, and it would either have to check or *trust* the initial construction from pointer+length.)

The C++ Core Guidelines talk about zstring as an alias for char*, to document intent.

That said, in the given use-case, I am not clear how zstring_view as a base-class for std::string solves the problem of ownership. Maybe I'm misunderstanding, but if you put a char* from a C API into a string_view, what's the mechanism to release it?

Perhaps this is something more cleanly solved using std::pmr::string. I feel that the actual problem here requires type-erasure, and that introduces a virtual hierarchy.

[Thiago Macieira]

On Sunday, 3 September 2017 02:21:24 -03 Paul "TBBle" Hampson wrote:
> That said, in the given use-case, I am not clear how zstring_view as a
> base-class for std::string solves the problem of ownership. Maybe I'm
> misunderstanding, but if you put a char* from a C API into a string_view,
> what's the mechanism to release it?

Same as any other use of string_view: you ensure that it outlives the
string_view object.

How you do that, that's your business and out-of-scope.

[Richard Hodges]

IMHO the only 'safe' interface for the constructor of a string_view is one of:

(const char* first, const char* last), or 

(const char* first, size_t length), or

(Iter first, Iter last)

Now you can't create one by accident and cause a segfault without meaning to.

But of course, then a string_view would simply be a specialisation of any pair of pointers delimiting a range of contiguous objects - which is what boost range is, is it not?

As to the question, yes I think a better design would be for :

string_view to be derived from basic_immutable_char_range<SomeImpl>

and string to be derived from basic_mutable_char_range<SomeImpl> which itself would be derived from basic_immutable_char_range<SomeImpl>

Where SomeImpl describes the storage mechanism, null-termination handling and concatenation/extension/shortening policies.

Now supply string algorithms as free functions rather than member functions.

non-mutating algorithms could be written in terms of basic_immutable_char_range<SomeImpl>'s interface while mutating algorithms could be written in terms of basic_mutable_char_range<SomeImpl>'s interface. Now there's only one algorithm to maintain for (for example) substr and conversions can be handled gracefully - you can create a mutable object from a non-mutable one (by copying contents) but you can't create a non-mutable one from a mutable one unless by explicitly mentioning its iterators.

std::string's SomeImpl  could now be based on std::vector, increasing code-reuse and providing the ability to move a vector into a string or vice verse. Something that would be useful perhaps when buffering I/O.

 

[Nicol Bolas]

On Monday, September 4, 2017 at 9:34:38 AM UTC-4, Richard Hodges wrote:

IMHO the only 'safe' interface for the constructor of a string_view is one of:

(const char* first, const char* last), or 

(const char* first, size_t length), or

(Iter first, Iter last)

Now you can't create one by accident and cause a segfault without meaning to.

But of course, then a string_view would simply be a specialisation of any pair of pointers delimiting a range of contiguous objects - which is what boost range is, is it not?

As to the question, yes I think a better design would be for :

string_view to be derived from basic_immutable_char_range<SomeImpl>

and string to be derived from basic_mutable_char_range<SomeImpl> which itself would be derived from basic_immutable_char_range<SomeImpl>

Any such range types would ultimately store pointers to the data, right? So, how would `std::string` be able to do SSO over the data in the base class?

It can't. It would have the SSO buffer in addition to the pointers in the base class.

That's bad.

[Richard Hodges]

> Any such range types would ultimately store pointers to the data, right? So, how would `std::string` be able to do SSO over the data in the base class?

> It can't. It would have the SSO buffer in addition to the pointers in the base class.

I disagree with your analysis.

The StorageImpl object of std::string would necessarily be of a different type to the StorageImpl of the string_view (the data is mutable and extendible for a start). As long as it has a correct interface there's no problem, and no reason it can't implement SSO at all.

 

[Nevin Liber]

On Mon, Sep 4, 2017 at 12:28 PM, Nicol Bolas <jmck...@gmail.com> wrote:

On Monday, September 4, 2017 at 9:34:38 AM UTC-4, Richard Hodges wrote:

IMHO the only 'safe' interface for the constructor of a string_view is one of:

(const char* first, const char* last), or 

string_view sv0(GetCString(), GetAnotherCString());

Doesn't seem safe to me.

 

(const char* first, size_t length), or

const char* ccs = Foo();

string_view sv(ccs, strlen(ccs));

// in another file

const char* Foo() {

    // ...

    if (CannotCreateString())

        return nullptr;

    // ...

}

Doesn't seem safe to me.

 

(Iter first, Iter last)

list<char> lc = Bar();

string_view sv2(lc.begin(), lc.end());

Doesn't seem safe to me.

Oh, and in case you think the solution to safety is to pass the container:

string_view Baz()

{

    vector<char> vc = GetVector();

    

    // equivalent to string_view(vc.data(), vc.data() + vc.size())

    return string_view(vc); 

}

Doesn't seem safe to me.

It's been in Boost (originally spelled string_ref, like the original proposal) since at least 2012, yet for some reason the C++ world hasn't ceased to exist.

I've used it in two code bases so far and have recommended it for a third, and I haven't seen the problems alleged here.

string_view has reference semantics.  Like language level references, anywhere you treat it as if it has value semantics is potentially a bug if you aren't being careful.  This is not news or new information.

-- 

[Richard Hodges]

> string_view sv0(GetCString(), GetAnotherCString());

Strawman argument. We could do the same with the initialisation of any container. But not blindly by accident. 

> if (CannotCreateString())

>        return nullptr;

Another straw-man. Returning raw pointers is already something we avoid in new code and encapsulate in old code. We can return unique_ptr's, empty std::optionals, or std::variant<Result, Error>. We have plenty of tools to avoid this nonsense.

> list<char> lc = Bar();

> string_view sv2(lc.begin(), lc.end());

Not a concern. Obviously we'd have some enable-iffery or static_assertery to guard against this. The iterators clearly need to be iterators over the same container of contiguous objects. That is trivially enforced at compile time.

> return string_view(vc); 

This is as much a code-reviewable error as:

x = std::move(y); foo(y); would be

Because obviously we never deliberately return references to stack-based objects, whether they are encapsulated in a fancy new class or not.

> Doesn't seem safe to me.

None of these straw-men were safe, and we all know it. Utterly irrelevant.

The non-safety comes from the implicit convertibility.

You say you have not yet had a problem in 2 projects. I am happy to accept this. And this in no way is a guarantee that there is no UB there that you simply haven't found yet. Because that's how UB works. 

I put it to you that if pressed, you'd find it very difficult to *prove* that there is no UB on some code path, or that some user or maintainer of your project won't introduce it without meaning to. 

Unless perhaps the only time you ever use std::string_view is when accepting an argument and you never copy one or store one somewhere. 

If that's the case, why not just construct static const strings at the program start and accept const char& - The program is then just as quick and 100% safe (at least in this regard).

> string_view has reference semantics.  Like language level references, anywhere you treat it as if it has value semantics is potentially a bug if you aren't being careful.  This is not news or new information.

Completely agree. And if constructing a reference_wrapper from std::ref (which deletes the rvalue-ref constructor) is the correct way to build a copyable reference, then it's also the correct way to build a string_view, which is fundamentally a copyable reference which happens to also carry a size() attribute.

Similarly r-value references decay when used, force you to remind yourself that you really want an r-value and the object is not in an undefined state - safety catch.

Similarly unique_ptr replaced auto_ptr - to provide a double check that the programmer really did mean to move the state out of it and wasn't able to do it 'accidentally' - safety catch.

I know I don't need to remind you that a program with UB in it, no matter how fast or convenient to write, is worse than no program at all.

--

[Richard Hodges]

> and accept const char&

forgive me, I meant to write "const std::string&"

[Nicol Bolas]

The question ultimately comes down to two pieces of code.

1: This is undeniably safe:

void some_func(string_view s);
some_func("a string"s);

2: This is undeniably broken:

std::string some_func2();
string_view sv = some_func2();

Is it more important for the latter to be explicitly non-functional or for the former to be explicitly functional?

Because quite frankly, this question has already been answered in other standard C++ APIs. Indeed, the initial `span` proposal explicitly deleted the `const&` constructor from container types to prevent exactly this circumstance. But the standards committee requested that it be reinstated, for circumstances like the first one, which are completely safe.

Consider Boost's range adaptors. I haven't used the most recent versions, but I don't recall any deletion of `operator|` overloads that could be called with rvalues. And that's far more dangerous than this sort of implicit conversion.

C++ is not a safe language. And valuing safety over clarity (and whatever you may want to say, `some_func("a string"s);` is perfectly clear code) is not what we do.

That's not to say that the problem is not important; I feel that it is. But the problem is caused by the language not being able to differentiate between 1 and 2. Until we have a way to forbid 2 without forbidding 1, I feel that we should not a priori forbid 1 simply to prevent 2.

[Richard Hodges]

> 1: This is undeniably safe:

There is another very pertinent case that you've missed, I'll get to that in a moment, first:

void some_func(string_view s);
some_func("a string"s);

It is certainly safe, but it is by no means the only elegant way to express the intent.

another would be:

some_func("a string"); // because a string_view can obviously be implicitly safely constructed from a string literal. And indeed, in this case, why do we want to create a string at all? This is a pessimisation.

another would be

some_func("a string"sv); // where the sv suffix produces a string_view from a literal, as above.

another would be 

some_func(string_view("a string"s)); // which really does not impede readability at all, and is now a more obvious inelegant pessimisation.

Of the 4 alternatives, some_func("a string"s); is the least optimised and most un-necessary of all of them. So why go out of our way to allow it, while at the same time reducing the safety of legacy code?

What do I mean by "reducing the safety of legacy code" ?

Well imagine some class CurrencyPair (it's a common one in c++ programs right?)

and imagine there is an accessor called auto CurrencyPair::base() -> std::string { return ccypair_.substr(0, 3); }; (for 3, 3 - i always forget which is which).

And now that c++17 is out, someone thinks, "wait a minute - i can save some clock cycles here for all users of this library".

And the CurrencyPair class gets refactored to : auto CurrencyPair::base() -> std::string_view { return std::string_view(ccypair_).substr(0, 3); };

Because why not, right? it's better because now we're not copying strings. (in the naive mind of the maintainer, fresh out of university), perhaps forgetting about SSO, modern cpu architecture and how std::string and the processor really work.

Of course all his unit tests will pass.

Now I make a quick update to my program which uses his library. I see that his library has a new version, fully tested, passing regression tests.

but my code contains this:

auto term = trade.get_ccy_pair().invert().term();             // once upon a time, term was a string. Now it's a string_view to a dead object.

auto interest_rate = market_data.get_base_rate(term); // which is a problem, is it not?

Now despite all the regression tests, and the unit tests in the library, I have UB.

My regression tests may even pass perfectly, because of course my regression tests are not taking place in the context of 64 concurrent threads processing 100,000 trades a second. But the live system is.

And one day, someone's trade will fail (if we're lucky), or will be computed with the wrong interest rate, or maybe we'll close out a customer on a false margin call and wipe him out - and he'll sue us.

And that my fellow c++ lovers, is why this implicit conversion is a bad idea.

Because it's UB waiting to happen in code that was working and now is not. All because we wanted to save a few keystrokes, or chase some nebulous ideal of "elegance".

We can argue the theoretical whys and wherefores all we like, but this is the UB-fest that awaits every organisation who upgrades to c++17 and thinks, "hey - this string_view thing... looks nifty..."
 
And with that, I feel I have given the committee and the c++ community fair warning of something they really ought to already know.

You have re-introduced raw pointers into a language that was working hard to eliminate them.

For shame.

--

[Matthew Woehlke]

On 2017-09-04 18:43, Nicol Bolas wrote:
> The question ultimately comes down to two pieces of code.
>
> 1: This is undeniably safe:
>
> void some_func(string_view s);
> some_func("a string"s);
>
> 2: This is undeniably broken:
>
> std::string some_func2();
> string_view sv = some_func2();
>
> Is it more important for the latter to be explicitly non-functional or for
> the former to be explicitly functional?

Yes.

You are making an implicit assumption there that symmetry is more
important than both. I dispute that assumption.

Yes, symmetry is *desirable*, but I would argue that having both of the
above is more important in this instance.

> C++ is not a safe language.

"C++ is the language that won't just let you shoot yourself in the foot;
it will cheerfully load the gun for you, help you aim, and offer you a
drink to help steady your nerves." (Slightly paraphrased.)

> That's not to say that the problem is not important; I feel that it is. But
> the problem is caused by the language not being able to differentiate

> between 1 and 2. Until we have a way to forbid 2 *without* forbidding 1, I

> feel that we should not a priori forbid 1 simply to prevent 2.

Huh? Construction and assignment *are* different operations...

string_view(std::string const&);
void operator=(std::string&&) = delete;

#1 works. #2 is explicitly prevented.

--
Matthew

[Ville Voutilainen]

On 5 September 2017 at 18:29, Matthew Woehlke <mwoehlk...@gmail.com> wrote:
> Huh? Construction and assignment *are* different operations...
>
> string_view(std::string const&);
> void operator=(std::string&&) = delete;
>
> #1 works. #2 is explicitly prevented.

string_view, by design, doesn't depend on string in its interface.

[Matthew Woehlke]

On 2017-09-04 20:43, Richard Hodges wrote:
>> 1: This is undeniably safe:
>
> There is another very pertinent case that you've missed, I'll get to that
> in a moment, first:
>
> void some_func(string_view s);
> some_func("a string"s);
>
> It is certainly safe, but it is by no means the only elegant way to express
> the intent.

That example borders on reductio ad absurdum. Here's a (slightly) better
example:

void some_func(string_view s);
some_func(std::to_string(3.14159));

Yes, passing a 'literal' std::string is silly. More likely, you are
calling some other function that produces a std::string.

See also the example from https://svn.boost.org/trac10/ticket/12917.

> auto term = trade.get_ccy_pair().invert().term();

D'oh. What we need here is a way to have different ctor overloads
depending on whether the object being constructed is a temporary or not.
(Can we do that already? I don't think so?)

I think that would work. Then we can mark the string&& ctor as deleted
for a non-&& string_view, but allow it for a string_view&&.

Basically, allow &- and &&-qualification on ctors, like we already do on
regular members.

(And *this* would be what I was talking about earlier when I suggested
that maybe we should wait until we have "better tools to prevent
this sort of thing".)

--
Matthew

[Howard Hinnant]

On Sep 4, 2017, at 8:43 PM, Richard Hodges <hodg...@gmail.com> wrote:
>
> And now that c++17 is out, someone thinks, "wait a minute - i can save some clock cycles here for all users of this library".
>
> And the CurrencyPair class gets refactored to : auto CurrencyPair::base() -> std::string_view { return std::string_view(ccypair_).substr(0, 3); };
>
> Because why not, right? it's better because now we're not copying strings.

This is a great example, and I think the beginning of a good guideline.

Don’t allow references to be returned from rvalues. Enforce like this:

auto
CurrencyPair::base() &

-> std::string_view
{
return std::string_view(ccypair_).substr(0, 3);
};

One could even overload:

auto
CurrencyPair::base() &&

-> std::string
{
return ccypair_.substr(0, 3);
};

Howard

[Richard Hodges]

>This is a great example, and I think the beginning of a good guideline.

> Don’t allow references to be returned from rvalues.  Enforce like this:

In actual fact, in this motivating example, in order to maintain utility the library maintainer would have to provide 2 overloads on this newly refactored CurrencyPair class wouldn't he? The motivating example returned a temporary CurrencyPair.

In which case the refactorer now has to supply 2 almost-identical overloads:

struct CurrencyPair

{

auto base() const& -> std::string_view; // sort of safe, provided the caller does not assign to an auto unwittingly

auto base() && -> std::string; // perfectly safe.

};

This idiom is going to be common. It therefore cries out for a standard idiom or policy, through which standard functions like substr should operate in order to deduce a safe return type. And it really ought to be enforced by the standard.

If I knew how to make a proposal it would be something along lines like this:

int main()

{

using namespace std::literals;

// ss1 will be a string by default

auto ss1 = std::substr("hello world"sv, 6, 5);

// ss2 will be a string by default

auto ss2 = std::substr("hello world"s, 6, 5);

// this mistake now can't happen

// auto ss3 = std::substr("hello world"s, 6, 5, std::prefer_speed);

// ss4 is a string_view that points into the literal

auto ss4 = std::substr("hello world"sv, 6, 5, std::prefer_speed);

auto hw = std::string("Hello World");

// this will be a string_view because we asked for a policy override

auto ss5 = std::substr(hw, 6, 5, std::prefer_speed);

static_assert(std::is_same<decltype(ss1), std::string>());

static_assert(std::is_same<decltype(ss2), std::string>());

static_assert(std::is_same<decltype(ss1), std::string>());

static_assert(std::is_same<decltype(ss4), std::string_view>());

static_assert(std::is_same<decltype(ss5), std::string_view>());

}

And we'd achieve it along lines similar to this:

namespace std {

template<class Tag> struct string_return_type_policy {};

template<>

struct string_return_type_policy<struct speed_over_safety_tag>

{

static auto to_result_type(string_view sv) { return sv; };

};

template<>

struct string_return_type_policy<struct safety_over_speed_tag>

{

static auto to_result_type(string_view sv) { return string (sv.begin(), sv.end()); };

};

constexpr auto prefer_safety = string_return_type_policy<struct safety_over_speed_tag>{};

constexpr auto prefer_speed = string_return_type_policy<struct speed_over_safety_tag>{};

auto substr_op(std::string_view sv, int pos, int len) -> std::string_view

{

// implementation_here

}

template<class Policy = decltype(prefer_safety)>

decltype(auto) substr(std::string_view sv, int pos, int len, Policy policy = prefer_safety)

{

return policy.to_result_type(substr_op(sv, pos, len));

}

template<class Policy = decltype(prefer_safety)>

decltype(auto) substr(std::string const& sv, int pos, int len, Policy policy = prefer_safety)

{

return policy.to_result_type(substr_op(sv, pos, len));

}

decltype(auto) substr(std::string && sv, int pos, int len, decltype(prefer_speed) policy) = delete; // this one's important!

}

Code on godbolt:

https://godbolt.org/g/LygFnD

[Nevin Liber]

On Wed, Sep 6, 2017 at 11:28 AM, Richard Hodges <hodg...@gmail.com> wrote:

>This is a great example, and I think the beginning of a good guideline.

> Don’t allow references to be returned from rvalues.  Enforce like this:

In actual fact, in this motivating example, in order to maintain utility the library maintainer would have to provide 2 overloads on this newly refactored CurrencyPair class wouldn't he? The motivating example returned a temporary CurrencyPair.

In which case the refactorer now has to supply 2 almost-identical overloads:

struct CurrencyPair

{

auto base() const& -> std::string_view; // sort of safe, provided the caller does not assign to an auto unwittingly

auto base() && -> std::string; // perfectly safe.

};

This idiom is going to be common.

I sure hope not.  Having two unrelated return types based on rvalue/lvalueness is a recipe for disaster.

sttring_ref has been in existence in Boost for five years.  Please provide links to the many projects which use the idiom you describe.

[Richard Hodges]

> 

This idiom is going to be common.

> I sure hope not.  Having two unrelated return types based on rvalue/lvalueness is a recipe for dis

I mean the idiom to implement Howard's new guideline. Which will only have to exist because string_views can be constructed from temporary strings.

--

[Howard Hinnant]

On Sep 6, 2017, at 12:36 PM, Nevin Liber <ne...@eviloverlord.com> wrote:
>
> On Wed, Sep 6, 2017 at 11:28 AM, Richard Hodges <hodg...@gmail.com> wrote:
>> >This is a great example, and I think the beginning of a good guideline.
>>
>> > Don’t allow references to be returned from rvalues. Enforce like this:
>>
>> In actual fact, in this motivating example, in order to maintain utility the library maintainer would have to provide 2 overloads on this newly refactored CurrencyPair class wouldn't he? The motivating example returned a temporary CurrencyPair.
>>
>> In which case the refactorer now has to supply 2 almost-identical overloads:
>>
>> struct CurrencyPair
>> {
>> auto base() const& -> std::string_view; // sort of safe, provided the caller does not assign to an auto unwittingly
>> auto base() && -> std::string; // perfectly safe.
>> };
>>
>> This idiom is going to be common.
>>
> I sure hope not. Having two unrelated return types based on rvalue/lvalueness is a recipe for disaster.

To me it looks like a good tool to have in the toolbox. Calling string and string_view unrelated seems like a stretch to me.

No worries. The first time I brought up move semantics for fstream, I was immediately shot down by a very high profile figure. Ditto for shared_ptr. Only time will tell if this is a good use of member function reference qualifiers or not.

>
> sttring_ref has been in existence in Boost for five years. Please provide links to the many projects which use the idiom you describe.

Problem is that boost (understandably) puts a premium on working with older compilers, and this C++ language feature was late to get implemented. These circumstances could easily be responsible for the suppression. … Or maybe you’re right and it’s a terrible idea. But so far you haven’t shown _why_ it is a recipe for disaster, so I’m unconvinced.

Howard

[Richard Hodges]

> To me it looks like a good tool to have in the toolbox.  Calling string and string_view unrelated seems like a stretch to me.

It's an interesting one, this relatedness issue.

For me, string and string_view are as distinct (possibly more distinct) than unique_ptr to reference_wrapper.

std::string_view attempts to deal with one concern - interrogating a sequence of characters (good!).

std::string attempts to deal with a number of concerns - I would argue that they are: interrogation, update, extending, storage lifetime management. (not so good, but history eh?)

Seen in that light, string and string_view are approximately 20% similar and 80% different.

I would certainly never want the language to allow me to confuse the two by accident.

Until c++11 it could not. We used to have to explicitly and laboriously write out types.

Now we hardly ever spell out types - auto and auto&& mean we don't have to.

The real problem, in my mind:

* all string manipulation functions should be free template functions, not methods.(1)

* whether the return of a mutating function is a copy or a reference should be specified in a policy

* a reference_wrapper requires explicit conversion and disallows conversion through an rvalue for good reasons. A string_view is basically a cleverer reference_wrapper. it should have the same conversion protection.

(1) for example boost.algorithm.string - a fantastic library which I use extensively, and would have been pleased to see in c++17

[Richard Hodges]

> But if `string` is a derived class of `string_view`, then `string` will contain `string::StorageImpl` and `string_view::StorageIm

I have not been clear.

consider:

template<class SomeStoragePolicy> struct immutable_string_concept;

template<class SomeStoragePolicy> struct mutable_string_concept : immutable_string_concept<SomeStoragePolicy>;

and note the different storage policy models:

struct immutable_reference_storage {};

struct mutable_extendable_sso_storage {};

struct mutable_memory_pool_storage {};

struct mutable_shared_storage {};

and so on.

and the default typedefs yielding our standard objects:

using string_view = immutable_string_concept<immutable_reference_storage>;

using string = mutable_string_concept<mutable_extendable_sso_storage>;

now substr() can be written in terms of immutable_string_concept<SomeStorageThatMayOrMayNotSupportMutation>

because it's a non-mutating algorithm.

but replace() can be written in terms of mutable_string_concept<SomeStorageThatSupportsMutation>

i.e. policy-driven code.

Then we wouldn't need a 'string_view' - immutable_string_concept is a basic concept for which we already have (template) free-function algorithms

Please note that I understand that I have been simplistic in the presentation of the storage models. They would in reality be composable.

From a blank sheet, this is certainly how I'd want to start.

To touch on the inheritance issue:

* a mutable string has all the capabilities of an immutable string concept, therefore inheritance seems correct.

* however the storage requirements of a mutable string are not compatible with those of a strictly immutable string. Hence the decoupling of the storage policy.

On 4 September 2017 at 21:03, Nicol Bolas <jmck...@gmail.com> wrote:

On Monday, September 4, 2017 at 2:44:28 PM UTC-4, Richard Hodges wrote:

> Any such range types would ultimately store pointers to the data, right? So, how would `std::string` be able to do SSO over the data in the base class?

> It can't. It would have the SSO buffer in addition to the pointers in the base class.

I disagree with your analysis.

The StorageImpl object of std::string would necessarily be of a different type to the StorageImpl of the string_view (the data is mutable and extendible for a start). As long as it has a correct interface there's no problem, and no reason it can't implement SSO at all.

But if `string` is a derived class of `string_view`, then `string` will contain `string::StorageImpl` and `string_view::StorageImpl`.

Inheritance is the wrong tool here. While they both model similar interfaces, they implement them differently.

[Nicol Bolas]

On Friday, September 8, 2017 at 9:47:18 AM UTC-4, Richard Hodges wrote:

> But if `string` is a derived class of `string_view`, then `string` will contain `string::StorageImpl` and `string_view::StorageIm

I have not been clear.

consider:

template<class SomeStoragePolicy> struct immutable_string_concept;

template<class SomeStoragePolicy> struct mutable_string_concept : immutable_string_concept<SomeStoragePolicy>;

We should not use policy-based inheritance for something so simple. If that's how an implementation wants to implement these things, fine. But it should not be forced to do so, nor should users be forced to use such policies.

[Richard Hodges]

> We should not...

citation needed. :)

[Ville Voutilainen]

On 8 September 2017 at 18:06, Richard Hodges <hodg...@gmail.com> wrote:
>> We should not...
>
> citation needed. :)

That's an opinion statement, not a reference to any rule.

[Victor Dyachenko]

On Wednesday, September 6, 2017 at 6:18:48 PM UTC+3, Howard Hinnant wrote:

This is a great example, and I think the beginning of a good guideline.

Don’t allow references to be returned from rvalues.

It's disputable. Counterexample:

void eat(std::string_view );

eat(MakeCurrencyPair().base());

Perfectly safe.

[Richard Hodges]

> Perfectly safe.

eat(MakeCurrencyPair().base(policy::as_view));

even safer.

In the same way that std::move(x) is safer than the (for good reasons, disallowed) implicit cast from x& to x&&.

Execution policies are part of c++17. Why not return value policies? In this way the 'return by reference' behaviour is explicitly stated in the code.

[Nicol Bolas]

On Monday, September 11, 2017 at 12:09:00 PM UTC-4, Richard Hodges wrote:

> Perfectly safe.

eat(MakeCurrencyPair().base(policy::as_view));

even safer.

In the same way that std::move(x) is safer than the (for good reasons, disallowed) implicit cast from x& to x&&.

Execution policies are part of c++17. Why not return value policies? In this way the 'return by reference' behaviour is explicitly stated in the code.

Execution policies are necessary for parallel algorithms to actually do their jobs. This code works as-is without the policy.

The code already explicitly states its intent. The function `eat` explicitly takes a `string_view`. The function `base` explicitly returns a `string_view`. Why does the caller of `base` need to be more aware that the function he called returns the type that it explicitly says it returns?

Furthermore, if you have the right to change the parameters to `base`, then you have the right to change the name of `base`. So if you feel that it needs to be more explicit, you can call it `base_sv` or `base_ref` or whatever.

So why make it a parameter, when it could just be part of the name? Why make something long-winded, when the short version supplies sufficient information?

[Howard Hinnant]

Overloading on:

string_view base() &; // references *this
string_view base() const&; // references *this
string base() &&; // moves into return

Seems even safer. This doesn’t give the client an opportunity to give the wrong opportunity, and will be highly efficient for any use.

Or depending on the innards, maybe return string& in place of string_view for the lvalue cases.

Howard

[Richard Hodges]

> Overloading on:

> string_view base() &;        // references *this
> string_view base() const&;   // references *this
> string      base() &&;       // moves into return

> Seems even safer.  This doesn’t give the client an opportunity to give the wrong opportunity, and will be highly efficient for any use.

but, ...

const auto ccypair = CurrencyPair();

post(executor, [base = ccypair.base()] { eat(base); });

... sometime later... BOOM!... good luck finding that.

> Or depending on the innards, maybe return string& in place of string_view for the lvalue cases.

Which means *never* return a string_view. I completely agree.

And if the ridiculous implicit conversion from std::string wasn't a thing, this thread needn't exist.

There's no reason that someone in need of a string_view cannot write 

x(string_view(begin(y), end(y)));

or 

x(string_view(data(y), size(y)));

x(y) simply loses too much information - such as ownership semantics - with no warning.

[Ville Voutilainen]

On 11 September 2017 at 22:00, Richard Hodges <hodg...@gmail.com> wrote:
>> Or depending on the innards, maybe return string& in place of string_view
>> for the lvalue cases.
>
> Which means *never* return a string_view. I completely agree.

Except when it's perfectly fine to return a string_view, which may
well be the case for
a member function.

> And if the ridiculous implicit conversion from std::string wasn't a thing,
> this thread needn't exist.

Do tell what else you're going to do about it in addition to
continuing to complain about it,
despite explanations why it's not ridiculous.

> There's no reason that someone in need of a string_view cannot write
> x(string_view(begin(y), end(y)));
> or
> x(string_view(data(y), size(y)));

I have no intention to write anything of that sort if I have an object
of a type convertible to string_view.

> x(y) simply loses too much information - such as ownership semantics - with
> no warning.

clang-tidy can warn about it just fine once they fix the current bug in it.

[Nevin Liber]

On Wed, Sep 6, 2017 at 11:50 AM, Howard Hinnant <howard....@gmail.com> wrote:

Problem is that boost (understandably) puts a premium on working with older compilers, and this C++ language feature was late to get implemented.  These circumstances could easily be responsible for the suppression.  …  Or maybe you’re right and it’s a terrible idea.  But so far you haven’t shown _why_ it is a recipe for disaster, so I’m unconvinced.

Here is the problem:

struct A1

{

    std::string str() const { return s; }

    void mod() { s = "Launch the missiles " + s; }

    std::string s = "Photon Warrior";

};

struct A2

{

    std::string        str() const && { return s; }

    std::string const& str() const &  { return s; }

    void mod() { s = "Launch the missiles " + s; }

    std::string s = "Photon Warrior";

};

struct A3

{

    std::string      str() const && { return s; }

    std::string_view str() const &  { return s; }

    void mod() { s = "Launch the missiles " + s; }

    std::string s = "Photon Warrior";

};

template<typename T>

void TestIt()

{

    std::cout << __PRETTY_FUNCTION__ << '\n';

    auto s1 = T{}.str();

    std::cout << "s1: " << s1 << '\n';

    T t;

    auto s2 = t.str();

    std::cout << "s2: " << s2 << '\n';

    t.mod();

    auto s3 = t.str();

    std::cout << "s3: " << s3 << '\n';

    std::cout << "s2: " << s2 << '\n';

    std::cout << '\n';

}

A1 is the original, A2 is the refactor before C++17, A3 is the refactor for C++17.

In TestIt<A2>, the language rules for auto make s2 a std::string (as opposed to a std::string const&), which is a string that is distinct from t.s.

In TestIt<A3>, a type with reference semantics is returned instead of a language reference, so the rules for auto do not help here.  The call to t.mod() invalidates s2.

It isn't the language rules that I have an issue with; it is returning a different type (as opposed to returning a reference vs. a value to the same type) based on the reference qualifiers that concerns me, especially when one type has reference semantics and the other type has value semantics.  The distinction is just too subtle.

I am aware that some are making the same argument against string_view in general; I am not.  While the interaction between auto and string_view isn't great, it isn't hard to document that there are reference semantics here and one has to be just as careful as they are with references, even though the syntax may not indicate as such.

-- 

[Howard Hinnant]

That’s a great example Nevin, thanks for the code.

I agree, A2 looks best, though I would be tempted to tweak it like this:

std::string str() && { return std::move(s); }

Personally I still have limited experience with string_view, and to-date have only used it as a function parameter to avoid overloading (const string&) and (const char*), the latter being done to prevent std::string construction for performance reasons (and this use case requires the implicit string -> string_view conversion). So far I haven’t stumbled across any gotchas in that use case. But clearly it seems string_view needs to be used with care.

Howard

[Richard Hodges]

> So far I haven’t stumbled across any gotchas in that use case.  But clearly it seems string_view needs to be used with care.

You are an expert. You would be able to return raw pointers and still write safe code, because you think carefully about the implications of what you do.

Of course you haven't stumbled on any gotchas - neither will I.

In its current form, string_view is an expert tool, like pointers and like reference_wrappers.

It's not you, me and the people in this thread who will be surprised, confounded and disheartened by string_view.

It is the beginners and intermediates who have learned that "auto x = y" takes a copy who will be getting the segfaults. They have learned that because until today it was true. c++ truly took a step back in time today.

I think I've said all I can on this subject. There's clearly a very strong body of opinion that safety is a reasonable sacrifice for avoiding the minor inconvenience of an explicit conversion.

I happen to think that this is a very sad state of affairs, and completely un-necessary.

Time will no doubt tell.

R

[Ross Smith]

On 2017-09-12 10:36, Richard Hodges wrote:
>
> You are an expert. You would be able to return raw pointers and still
> write safe code, because you think carefully about the implications of
> what you do.
>
> Of course you haven't stumbled on any gotchas - neither will I.
>
> In its current form, string_view is an expert tool, like pointers and
> like reference_wrappers.
>
> It's not you, me and the people in this thread who will be surprised,
> confounded and disheartened by string_view.
>
> It is the beginners and intermediates who have learned that "auto x = y"
> takes a copy who will be getting the segfaults. They have learned that
> because until today it was true. c++ truly took a step back in time today.
>
> I think I've said all I can on this subject. There's clearly a very
> strong body of opinion that safety is a reasonable sacrifice for
> avoiding the minor inconvenience of an explicit conversion.
>
> I happen to think that this is a very sad state of affairs, and
> completely un-necessary.
>
> Time will no doubt tell.

Richard, I can't help thinking you kind of sabotaged your own case here
by bringing this up so late in the day.

Your arguments aren't entirely without merit; I think most of us will
agree that you do have a point about potential problems with
string_view. Whether those problem outweigh the convenience of it is
a legitimate debate. The problem you keep failing to acknowledge is
that _it's too late now_. If you'd brought this up two or three years
ago, when C++14 was fresh off the boat and people were starting to
discuss what should go in C++17, they might have been more receptive
to changes to string_view. But now it's in an accepted standard and
in a lot of actual existing code out there in the wild. I don't think
even the second coming of gets() could persuade the committee to do
that much violence to existing implementations now. Sorry.

Everyone, presumably including you, has known about string_view for
many years now; why did you leave it so late to raise any objections?

Ross Smith

[Richard Hodges]

> Everyone, presumably including you, has known about string_view for

many years now; why did you leave it so late to raise any objections?

There is no well-known public forum for this kind of discussion. The vast majority of c++ users are not part of the committees' process. I think it would be healthy if there was a more public forum, and indeed a contribute-able git repo and issue tracker. It would be more healthy.

 I have no objection to a "range of chars" object per-se. I saw that one was coming, thought "that's nice" and dismissed it because until the new standard comes out and is supported directly by all compiler vendors, our projects will remain on c++14.

It never occurred to me that the implicit conversion would be slipped in on the std::string interface. It's such a counterproductive idea.

Who would modify a perfectly well known interface and create a dependency between two unrelated classes? And yes, they are unrelated. They do very different things. Std::string is 80%resource management, string_view merely supports a limited set of string queries. 

So here is your first user feedback. From someone who mandates the use of standard-compliant c++ in his organisation, because he trusts the committee when they say, "it should be hard for people to do bad things". 

That trust has been tarnished with string_view. The impression here is committee is no longer favouring correct programs of explicit intent. it is favouring a single moment of convenience over correctness.

C++11 allowed me to make the case that c++ was still the correct, viable and dependable language for our software stack. String_view damages that argument. Because now I will have to hire only experts, beginners will once again become a liability. And I can't afford a segfault on a production server.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.

[Nicol Bolas]

On Tuesday, September 12, 2017 at 1:35:50 AM UTC-4, Richard Hodges wrote:

> Everyone, presumably including you, has known about string_view for

many years now; why did you leave it so late to raise any objections?

There is no well-known public forum for this kind of discussion. The vast majority of c++ users are not part of the committees' process. I think it would be healthy if there was a more public forum, and indeed a contribute-able git repo and issue tracker. It would be more healthy.

OK, let's say that such a forum existed. And that you found it in 2015. And that you actually paid attention to the various proposals, read the details, saw the implicit conversion and challenged it. You made your case on this forum and... your case was rejected by the committee. That is, they considered your concerns, but decided to allow implicit conversions anyway.

Would you consider that "healthy"? Because if you would, then that means you assume that your concerns are new, that they're not something the committee has heard before. And if you wouldn't consider it "healthy", then you're determining whether the process is good or bad based solely on whether it has good results, not on the actual process itself.

 I have no objection to a "range of chars" object per-se. I saw that one was coming, thought "that's nice" and dismissed it because until the new standard comes out and is supported directly by all compiler vendors, our projects will remain on c++14.

So, exactly how would a forum have helped in this case? You clearly weren't particularly engaged on the matter of upcoming standards. How would having a forum improve this?

 

It never occurred to me that the implicit conversion would be slipped in on the std::string interface. It's such a counterproductive idea.

You say "slipped in" as though:

1: Implicit conversion from `string` to `string_view` was not always part of the proposal. Whether the conversion was `string_view::string_view(const string &)` or `string::operator string_view()`, it was always there.

2: There was not a specific proposal moving the implicit conversion from `string_view` to `string`. A proposal made 1 year ago.

You didn't pay attention to what was going on. I don't see how a forum would have helped.

Who would modify a perfectly well known interface and create a dependency between two unrelated classes? And yes, they are unrelated. They do very different things. Std::string is 80%resource management, string_view merely supports a limited set of string queries. 

So here is your first user feedback.

I find it truly remarkable that you assume that you're the first "user" to give the committee feedback. As though the committee were somehow completely divorced from the community of C++ users.

From someone who mandates the use of standard-compliant c++ in his organisation, because he trusts the committee when they say, "it should be hard for people to do bad things".

Principles are not bludgeons. If it makes the language better to side-step a principle (usually, in favor of another principle), then we should do that.

C++ also is supposed to operate under the "don't pay for what you don't use" principle. And yet, you'll see plenty of places in the standard where that's violated. `iostreams` being a great example of a place where we're constantly paying for things we aren't necessarily using.

And we still don't have a way to deal with constructor failures without heavy-weight exception handling.

To you, the principle of "don't break things" is more important than the principle of "don't repeat yourself". Or the principle of "make the simple things simple." These are all arguable points, and those arguments have been made. The resolution is not one you agree with.

But that doesn't make it wrong.

That trust has been tarnished with string_view. The impression here is committee is no longer favouring correct programs of explicit intent. it is favouring a single moment of convenience over correctness.

C++11 allowed me to make the case that c++ was still the correct, viable and dependable language for our software stack. String_view damages that argument. Because now I will have to hire only experts, beginners will once again become a liability.

Seriously? One implicit conversion, and you immediately start not hiring people, not because they will misuse something, but because they might? Even though those same people could have taken 5 minutes to write `string_view` with that implicit conversion and misuse it?

Your logic is... interesting.

[Richard Hodges]

> But that doesn't make it wrong.

The level of defensiveness I see tells me that deep down, you know it's wrong.

> Seriously? One implicit conversion, and you immediately start not hiring people

There used to be a fairly well-known adage that it takes anyone at least two years to get to the level of competence with c++ that they can be let loose in a production environment.

This was largely because of the ubiquitous use of pointers and a lack of formal methods for managing object lifetimes in a standard way.

It seems to me that we're heading back that way.

> And we still don't have a way to deal with constructor failures without heavy-weight exception handling.

This is a whole other area of pointless navel-gazing. We have std::variant<Val, Error> (and have had boost's versions for aeons) for the result of a maybe construction via a factory function. Both Val and Error can easily be made exception-free.

In any case, exceptions are only (marginally) expensive when they fire. The cost of checking whether an exception occurred in compiled code is less than the cost of switching on a variant's discriminator. 

Any performance loss people may imagine they suffer from exceptions being the only way to signal the non-creation of an object (they don't) is that in c++, objects are either created fully or they don't exist. That's *fantastic*. It means you never have to put null_ptr checks in logic. Every null_ptr check we don't have to do is a conditional branch we don't have to execute, an error case we don't have to write. Who wouldn't want that?

Finally,

C++ needs fewer pointless arguments over whether c++ objects really occupy bytes in memory or not. I refer of course to the infamous nonsense of "std vector not being really legally implementable in c++."

C++ needs better real-world standardised support. Networking, graphics, console, input devices, crypto, framing protocols, HTTP (version 1.1 having been invented a mere 20 years ago). So people can actually use it to do something useful out of the box. Boost is starting to go this way, thank goodness. But try to get a fully correct c++14 build of boost working, with ICU support in regex and SSL support in asio, on an ipad within a day. OMG! The number one complaint I get from my team is that they spend more time on building dependencies and tuning the build system than they do writing code - we write cross-platform, windows, linux, osx, ios, android. My Java guys can't believe the nonsense we have to go through just to get a program to compile.

C++ needs standardised packaging support. Like javascript's package.js. At the moment, the best cross-platform dependency manager I have found is the combination of CMake and hunter (github.com/ruslo/hunter). It's good, but nowhere near as comprehensive as npm, gulp, et. al.

C++ needs more focus on making it useable, and less on inflicting intermediate users with a list of 100 things that 'thou shalt not do because it's dangerous'. For years we have been encouraging people to "express intent succinctly in code, let the compiler work out the optimisation". This was good advice. Compilers are getting really good. To make your program go faster, assuming you chose the correct algorithm, simply download a newer version of the compiler. For the general case, there is no need for a micro-optimisation like string_view. Any string you ever create, you'll eventually hand off to an OS to do some IO. The performance argument ends right there.

After the release of c++11 I watched Herb Sutter's talk on how in future the c++ standard could include a 3d graphics interface. I was stunned, enthused. "There's life in the old c++ dog yet", I thought. But no. We've had 6 years of dithering over whether to include networking-ts or not.

My son wants to learn c++ to write a game (of course that's how almost everyone starts, right?). So I sat him down and explained about how we need to choose a graphics engine library, a sound library, maybe create some abstractions around os-specific stuff. You could see him losing interest. "What you mean is", he said, "is that the language isn't complete."

Whether you take issue with my tone is unimportant. What I think is important is that the momentum that came from the c++11 release has been lost, and we're back to stagnant circular discussions about minutiae.

If you think c++ is a good thing as I do, you ought to feel that that's important too.

To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.

[Bruce Adams]

On Tuesday, 12 September 2017 17:55:57 UTC+1, Richard Hodges wrote:

> But that doesn't make it wrong.

The level of defensiveness I see tells me that deep down, you know it's wrong.

> Seriously? One implicit conversion, and you immediately start not hiring people

There used to be a fairly well-known adage that it takes anyone at least two years to get to the level of competence with c++ that they can be let loose in a production environment.

This was largely because of the ubiquitous use of pointers and a lack of formal methods for managing object lifetimes in a standard way.

It seems to me that we're heading back that way.

> And we still don't have a way to deal with constructor failures without heavy-weight exception handling.

This is a whole other area of pointless navel-gazing. We have std::variant<Val, Error> (and have had boost's versions for aeons) for the result of a maybe construction via a factory function. Both Val and Error can easily be made exception-free.

In any case, exceptions are only (marginally) expensive when they fire. The cost of checking whether an exception occurred in compiled code is less than the cost of switching on a variant's discriminator. 

Any performance loss people may imagine they suffer from exceptions being the only way to signal the non-creation of an object (they don't) is that in c++, objects are either created fully or they don't exist. That's *fantastic*. It means you never have to put null_ptr checks in logic. Every null_ptr check we don't have to do is a conditional branch we don't have to execute, an error case we don't have to write. Who wouldn't want that?

Finally,

C++ needs fewer pointless arguments over whether c++ objects really occupy bytes in memory or not. I refer of course to the infamous nonsense of "std vector not being really legally implementable in c++."

C++ needs better real-world standardised support. Networking, graphics, console, input devices, crypto, framing protocols, HTTP (version 1.1 having been invented a mere 20 years ago). So people can actually use it to do something useful out of the box. Boost is starting to go this way, thank goodness. But try to get a fully correct c++14 build of boost working, with ICU support in regex and SSL support in asio, on an ipad within a day. OMG! The number one complaint I get from my team is that they spend more time on building dependencies and tuning the build system than they do writing code - we write cross-platform, windows, linux, osx, ios, android. My Java guys can't believe the nonsense we have to go through just to get a program to compile.

C++ needs standardised packaging support. Like javascript's package.js. At the moment, the best cross-platform dependency manager I have found is the combination of CMake and hunter (github.com/ruslo/hunter). It's good, but nowhere near as comprehensive as npm, gulp, et. al.

C++ needs more focus on making it useable, and less on inflicting intermediate users with a list of 100 things that 'thou shalt not do because it's dangerous'. For years we have been encouraging people to "express intent succinctly in code, let the compiler work out the optimisation". This was good advice. Compilers are getting really good. To make your program go faster, assuming you chose the correct algorithm, simply download a newer version of the compiler. For the general case, there is no need for a micro-optimisation like string_view. Any string you ever create, you'll eventually hand off to an OS to do some IO. The performance argument ends right there.

After the release of c++11 I watched Herb Sutter's talk on how in future the c++ standard could include a 3d graphics interface. I was stunned, enthused. "There's life in the old c++ dog yet", I thought. But no. We've had 6 years of dithering over whether to include networking-ts or not.

My son wants to learn c++ to write a game (of course that's how almost everyone starts, right?). So I sat him down and explained about how we need to choose a graphics engine library, a sound library, maybe create some abstractions around os-specific stuff. You could see him losing interest. "What you mean is", he said, "is that the language isn't complete."

Whether you take issue with my tone is unimportant. What I think is important is that the momentum that came from the c++11 release has been lost, and we're back to stagnant circular discussions about minutiae.

If you think c++ is a good thing as I do, you ought to feel that that's important too.

I feel you are conflating a package repository like cpan or pypy with the standard library there.

Lots of languages have package repositories and they are full of libraries of varying quality. Some excellent and some awful. Like in C++ only a small subset are part of the official language. Though admittedly in many cases that small subset is larger than C++'s.

You still have to choose from many alternatives to do anything worthwhile of any size. That can be a daunting task to the uninitiated when closely examined or explained no matter what the language.

I see only increasing momentum with all the TS's coming out recently - coroutines, modules, ranges, concepts

A language is never complete in the sense you mean. There are plenty of library collections that are nearly complete in themselves for certain kinds of application. QT, WxWidgets, Poco, wtty. opencv ...

search engines turn the internet into a pretty good package repository though the amazing range of choices for build systems etc. are problematic as you point out.

Very few languages have got that right perhaps because people's needs vary so far.

Java has gone through numerous build systems, ant, maven, gradle

Python has had setup.py, pip and easy_install and eggs replaced by wheels etc.

It seems like everyone who builds a new language or package manager falls short of including and surpassing all previous learning in that area. Sometimes out of ignorance but more often simply because its a difficult problem and a good enough solution now beats a better solution in the future. That said I'm confident of progress.

Also

>>There is no well-known public forum for this kind of discussion. The vast majority of c++ users are not part of the committees' process. I think it would be healthy if there was a more public forum, and indeed a contribute-able git repo and issue tracker. It would be >>more healthy.

>OK, let's say that such a forum existed. And that you found it in 2015. And that you actually paid attention to the various proposals, read the details, saw the implicit conversion and challenged it. You made your case on this forum and... your case was rejected by the >committee. That is, they considered your concerns, but decided to allow implicit conversions anyway.

Isn't this that forum?

 

[p_ha...@wargaming.net]

On Wednesday, September 13, 2017 at 10:18:46 AM UTC+10, Bruce Adams wrote:

>>There is no well-known public forum for this kind of discussion. The vast majority of c++ users are not part of the committees' process. I think it would be healthy if there was a more public forum, and indeed a contribute-able git repo and issue tracker. It would be >>more healthy.

>OK, let's say that such a forum existed. And that you found it in 2015. And that you actually paid attention to the various proposals, read the details, saw the implicit conversion and challenged it. You made your case on this forum and... your case was rejected by the >committee. That is, they considered your concerns, but decided to allow implicit conversions anyway.

Isn't this that forum?

My understanding is that the above is a closer description of std-proposals than std-discussion. This forum is focused on the standard as it stands. https://isocpp.org/forums is where I get that idea from.

I believe that what std-proposals lacks to be the arena Richard was looking for, is that not *every* proposal passes through std-proposals, only those that're either posted there for feedback, or that someone sees and brings there for discussion.

[Nicol Bolas]

For what it's worth, the stuff he's complaining about is application-level stuff: XML parsing, HTTP handling, 2D graphics, etc. The current TS's are mostly "merely" useful tools.

You can make a web browser without coroutines; you can't make one without HTTP processing.

Personally, I don't think the C++ standard library is the place for application-level tools. The standard is an ISO standard; it progresses slowly by design. And that's good for a long-running standard.

But application-level stuff changes constantly. Just look at his notion of a 3D graphics library.

Since C++11 shipped, there have been 4 versions of OpenGL released. Not only that, there have been four brand new graphics APIs released, which are fundamentally different from just about any 3D APIs released before. Not to mention advances in texture compression, PBR techniques, VR, AR, and various other things that have significantly changed how 3D graphics gets done.

Even a high level 3D API that was initially conceived in 2011 would be completely obsolete today.

Standards need to be things that can stand the test of time.

Plus, there's the fact that the C++ standard must be implemented by multiple people. Most other languages with large standard libraries only have one primary implementation. Every major new element of the standard library has to be implemented at least 3 separate times: libc++, libstdc++, and MSVC.

That's a lot of work.

A language is never complete in the sense you mean. There are plenty of library collections that are nearly complete in themselves for certain kinds of application. QT, WxWidgets, Poco, wtty. opencv ...

search engines turn the internet into a pretty good package repository though the amazing range of choices for build systems etc. are problematic as you point out.

Very few languages have got that right perhaps because people's needs vary so far.

Java has gone through numerous build systems, ant, maven, gradle

Python has had setup.py, pip and easy_install and eggs replaced by wheels etc.

It seems like everyone who builds a new language or package manager falls short of including and surpassing all previous learning in that area. Sometimes out of ignorance but more often simply because its a difficult problem and a good enough solution now beats a better solution in the future. That said I'm confident of progress.

Also

>>There is no well-known public forum for this kind of discussion. The vast majority of c++ users are not part of the committees' process. I think it would be healthy if there was a more public forum, and indeed a contribute-able git repo and issue tracker. It would be >>more healthy.

>OK, let's say that such a forum existed. And that you found it in 2015. And that you actually paid attention to the various proposals, read the details, saw the implicit conversion and challenged it. You made your case on this forum and... your case was rejected by the >committee. That is, they considered your concerns, but decided to allow implicit conversions anyway.

Isn't this that forum?

Well, that would technically be over here. But I think he's expecting something more binding than that. That place is just a place to talk about ideas, perhaps make a dry-run on proposals, and get some feedback.

What he's looking for, I suspect, is a direct conduit to the committee. A place where he can lay out his arguments and the committee members would be expected to read them and respond.

[Richard Hodges]

> What he's looking for, I suspect, is a direct conduit to the committee. A place where he can lay out his arguments and the committee members would be expected to read them and respond.

Right, because, quis custodiet ipsos custodes?

To be honest, even a megalomaniac like me understands that that would require the committee to be fielding constant feedback from all over the world. However, I do think that proposals should be posted on a message board, the user base pinged, and then be given the opportunity to flag up issues like,

"yes, looks useful",

"no because dangling pointers"

"great, but this tweak will improve x"

and a git repo where people can post, 

"if we do it this way, we get these benefits - here's a demo"

and so on. Basically a standard stackoverflow. (which is the de-facto standard in consulting experts is it not?)

The lesson of the open source computing world is that collaboration and involvement from the user base accelerates development and improves products.

The current ISO arrangement, with its dark inner-circle of wise men, is frankly medieval. In that light, it's no surprise that c++ lags behind every other technology on the planet.

> Standards need to be things that can stand the test of time.

DirectX, for all its sins, lasted 20 years, each evolution compatible with the previous. Games that were written with it 20 years ago still run (under wine even!) on my mac. That is the magic of standards. Even imperfect ones.

I'm no great fan of many of Microsoft's technology decisions and implementations, but for that platform, there was a standard. It worked, and people got their products. OpenGL and X are also long-lived 'standards' that have worked well. They evolved, but they don't just get swept away.

The boost library evolves. boost.signals was followed by boost.signals2 - with a smooth transition. Same with boost threads versions 1 to 4. Same with boost qi, ranges etc etc. The user community copes because the evolutions in the boost "standard" are handled intelligently by the genuine heroes who maintain and contribute to boost.

The c++ standard should also evolve. No committee will get everything right first time. We have just dumped auto_ptr - the mainstay of dynamic memory management for 30 years. No-one has batted an eyelid. All the concerns over deprecation and dropping came to nothing. It turns out that people appreciate progress. We're not luddites - we love technology. We want to move forward.

If we just sit and wait for everything to be perfect before moving the standard forward, we get what we have now - a standard that's 30 years out of date, with no useful tools to actually make applications do anything. 

Developers have the choice of:

* Tie yourself to an OS vendor and their libraries, or

* write your own cross-platform abstractions and delay your project by [a long time], or

* throw yourself at the mercy of the chaos of open source libraries, or

* use a different language.

I understand the concerns of implementors of the standard library if the library gets big(ger).

There is no reason that the standards body cannot simply mandate standard interfaces and provide standard tests, and let the open-source and commercial communities code to those. I mean, we have libstc++, libc++ and microsoft's runtime. They're all more-or-less conforming. At least enough to write a single program for almost all target platforms without modification. 

The application interfaces should be similar. Libraries that provided the standard interface (i.e. passed the set of standard unit tests) could be so marked and certificated. This would give vendors encouragement and incentive to make them so, even if they provide their own custom interfaces as well. The market would converge on the standard. Developers could use the same code on all platforms, choosing *the best implementations* of standards-conforming libraries, rather than *whatever they can get*.

The modern paradigm in programming is to "express intent" and let the tools turn our intent into fantastic user experiences.

Currently we cannot "express intent" in a standard way in any other matter than the minutiae of string manipulation, launching a thread and iterating a container.

 

Whenever we touch the OS, we're back to hacking against proprietary interfaces.

c++ has a standard memory model - an abstract idea of what memory looks like.

It should also have a standard model of operating system features and peripherals - an abstract idea against which to code. Clearly the committee agrees in some way with this, otherwise we would not have a standard filesystem library.

Then we could elegantly express the intentions of our aliens, heroes, trading systems, flight computers and so on. And incremental improvements in vendors libraries and tools will cause our intent to be expressed even more vividly and efficiently.

[Thiago Macieira]

On quarta-feira, 13 de setembro de 2017 00:58:43 PDT Richard Hodges wrote:
> > What he's looking for, I suspect, is a direct conduit to the committee. A
> > place where he can lay out his arguments and the committee members would
be

> > *expected* to read them and respond.
>
> Right, because, *quis custodiet ipsos custodes?*

>
> To be honest, even a megalomaniac like me understands that that would
> require the committee to be fielding constant feedback from all over the
> world. However, I do think that proposals should be posted on a message
> board, the user base pinged, and then be given the opportunity to flag up
> issues like,

All proposals are posted on the committee's website. All committee members
also receive a notification that the mailing is available. Everyone and anyone
on the Internet can read them. There are lots of people who read them (like
me) and post comments to std-proposals.

Some of the proposal authors read the mailing lists and react. If not, some
other people may be convinced by your arguments and take the discussion to the
committee meeting. Finally, you can always just send your arguments to the
proposal author.

And, finally, you can go to the committee meetings. Nothing is happening behind
closed doors, all proceedings are open. You can show up and make your case why
you think something is bad or why something is good.

> and so on. Basically a standard stackoverflow. (which is the de-facto
> standard in consulting experts is it not?)

No, it's not.

> The lesson of the open source computing world is that collaboration and
> involvement from the user base accelerates development and improves
> products.

Indeed. The C++ standard is one of the most open standards I've had a chance
to work with, on par with IETF.

> The current ISO arrangement, with its dark inner-circle of wise men, is
> frankly medieval. In that light, it's no surprise that c++ lags behind
> every other technology on the planet.

First of all, your characterisation is wildly misplaced, at least when it
comes to C++. The C++ committee works around the ISO limitations and
requirements just fine. The discussions even at committee meetings include
everyone, so there's no "inner-circle" of men, women, wise or not, whether in
dark rooms or brighly lit. The fact that only national bodies can vote is
almost irrelevant, since all the technical discussions will have been hashed
out prior to that point. The NB comments are used simply to provide a last
attempt at fixing something at a very late stage. Not to mention that the
people representing the NBs are experts in their own accord and have been
present in the discussions.

Second, C++ is not lagging behind every other technology in the planet. That's
the kind of useless generalisation thrown about that discredits you. Please
pay attention to what you write.

I'll repeat what I said: the C++ standard is developed in one of the most open
ways I've seen when it comes to standards, on par with IETF.

> > Standards need to be things that can stand the test of time.
>
> DirectX, for all its sins, lasted 20 years, each evolution compatible with
> the previous. Games that were written with it 20 years ago still run (under
> wine even!) on my mac. That is the magic of standards. Even imperfect ones.

DirectX is not a good example, since it's not a standard and there's exactly
one implementation by one vendor.

Also note how there are lots of bugs with the DirectX drivers (and OpenGL for
that matter), so a lot of developers do have to apply work arounds so that
their applications work in the first place and continue to work.

> I'm no great fan of many of Microsoft's technology decisions and
> implementations, but for that platform, there was a standard. It worked,
> and people got their products. OpenGL and X are also long-lived 'standards'
> that have worked well. They evolved, but they don't just get swept away.

And yet OpenGL almost died for a time (proof: DirectX). It took a lot of
effort to get it back on track and to get everyone involved to work on the
next thing (Vulkan) without derailing it.

> The boost library evolves. boost.signals was followed by boost.signals2 -
> with a smooth transition. Same with boost threads versions 1 to 4. Same
> with boost qi, ranges etc etc. The user community copes because the
> evolutions in the boost "standard" are handled intelligently by the genuine
> heroes who maintain and contribute to boost.

And you do realise that string_view came from Boost among others, right? You
do realise that the committee standardised existing practice, in those
libraries that you're right now praising?

> The c++ standard should also evolve. No committee will get everything right
> first time. We have just dumped auto_ptr - the mainstay of dynamic memory
> management for 30 years. No-one has batted an eyelid. All the concerns over
> deprecation and dropping came to nothing. It turns out that people
> appreciate progress. We're not luddites - we love technology. We want to
> move forward.

Aye.

> If we just sit and wait for everything to be perfect before moving the
> standard forward, we get what we have now - a standard that's 30 years out
> of date, with no useful tools to actually make applications do anything.

Aye. Which is why we need std::string_view, imperfect though as it may be.
We're humans, we make mistakes. We just have to *learn* from those mistakes.

That said, there are a number of things you can do to make sure that you don't
shoot yourself in the foot. Hence peer reviews of code and a lengthy review
process for the standard.

> The application interfaces should be similar. Libraries that provided the
> standard interface (i.e. passed the set of standard unit tests) could be so

> marked *and certificated*. This would give vendors encouragement and

> incentive to make them so, even if they provide their own custom interfaces
> as well. The market would converge on the standard. Developers could use
> the same code on all platforms, choosing *the best implementations* of
> standards-conforming libraries, rather than *whatever they can get*.

I don't think you have a clue what it means to certify something, or the costs
involved. "It compiles" is not sufficient, q.v. "undefined behaviour".

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Richard Hodges]

> We're humans, we make mistakes. We just have to *learn* from those mistakes., and

> And you do realise that string_view came from Boost among others, right? 

I do. Here's a snippet of current source code of boost. See that comment?

// #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) && !defined(BOOST_NO_CXX11_DELETED_FUNCTIONS)

//       // Constructing a string_view from a temporary string is a bad idea

//       template<typename Allocator>

//         basic_string_view(      std::basic_string<charT, traits, Allocator>&&)

//           = delete;

// #endif

Do you see how this code has been commented out, but the comment-outer has tellingly not had the confidence in the action to actually delete the code?

Do you see how the original comment stands accusingly in defiance of this action? - "// Constructing a string_view from a temporary string is a bad idea"

Clearly Mr Clow realised that this was a bad idea - even as he was reluctantly reverting his perfectly sensible and well-thought-out commit.

No explanation given in the commit that reverts the change. Peer pressure from the almost-complete standard conflicting with common sense perhaps? Of course if you wanted boost::string_view to be a facsimile of std::string_view you'd have to do this, since there is no other way to inject the offending conversion operator into std::string from within the boost namespace. This is a clear case of a broken standard breaking boost. Not the other way around.

source: https://github.com/boostorg/utility/blob/master/include/boost/utility/string_view.hpp

Here are the relevant commits:

https://github.com/boostorg/utility/commit/00f02167e35861bd11b8a9d6585444e9ef0b5172

https://github.com/boostorg/utility/commit/6c4ab93573904f6d37f74c8819ac39cd230118e9

> I don't think you have a clue what it means to certify something, or the costs involved. "It compiles" is not sufficient, q.v. "undefined behaviour".

I think I must have hurt your feelings. You're on the brink of both staw-man and ad-hominem with this one.

I apologise. I am not here to discredit you personally. I am here so that information can flow back from an enthusiastic (and pretty good) c++ user to the people who are making the decisions about the language I have chosen over all others to care about.

>> and so on. Basically a standard stackoverflow. (which is the de-facto
>> standard in consulting experts is it not?)
> No, it's not.

I respectfully submit that you're a little behind the times (which is odd, because of the two of us I am certain that I am the older). There's an entire generation of developers, in all languages, who use stack-overflow as their primary source of programming-related information. For good reason - the information is collectively sourced and instantly peer-reviewed by a massive enthusiastic community of contributors. The vast majority of c++ developers will never read the standard. They will consult SO, and get complete, annotated information delivered by knowledgable experts on the subject - with examples.

The c++ standards committee could learn a lot from this model.

> DirectX is not a good example, since it's not a standard and there's exactly one implementation by one vendor.

There are exactly 12 iterations of the library suite from the original vendor. They are all compatible. As you are well aware, I was illustrating how interfaces can successfully evolve over time.

You mention bugs. These are a symptom of there being only one implementor. Had there been a c++ standard for 3d, there would have been multiple implementors competing. There would be fewer bugs. There are examples in the wild. Ogre3D, Irrlicht, etc. All of varying quality and approaches but all with the same sensible design goal - standardise the damned interface, get rid of problematic proprietary interfaces. These libraries were born out of need. If they're needed in the real world, then the concept is needed in the standard.

> The C++ committee works around the ISO limitations and requirements just fine.

> I'll repeat what I said: the C++ standard is developed in one of the most open ways I've seen when it comes to standards, on par with IETF.

Maybe, but still not good enough. I've been in technology long enough to know that committees are not the best way to achieve progress. Boost exists only because the standard isn't good enough.

> Aye.

Fantastic. We have a point of agreement. Let's work on that. Now that we agree that it's ok to bring something slightly imperfect out and refine it later, let's not delay networking, ranges, modules, executors and future continuations any longer, eh? 6 years is quite a long time to wait.

You know, those little things that are available out of the box in every other popular computer language.

Because of the committee, there is actually an opportunity to adopt an approach much more like boost. Progress in the c++ standard could be orders of magnitude faster. But with the advantage that there is a global authority underpinning it. At the moment it's a wasted opportunity.

  

[Hyman Rosen]

On Wed, Sep 13, 2017 at 12:20 PM, Richard Hodges <hodg...@gmail.com> wrote:

You know, those little things that are available out of the box in every other popular computer language.

I think having application level things, even such stuff as file access, be part of the language is a bad idea.  It's especially bad when the language tries to specify behavior without a standard implementation, given that the language allows user code to subvert all the mechanisms that the library should be using.

Here's what happened after the sixth(!) revision of Scheme:
<http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs.pdf>

In the fall of 2006, work began on a more ambitious standard, including many new improvements and stricter requirements made in the interest of improved portability.  The resulting standard, the R6RS, was completed in August 2007 [33], and was organized as a core language and set of mandatory standard libraries. Several new implementations of Scheme conforming to it were created. However, most existing R5RS implementations (even excluding those which are essentially unmaintained) did not adopt R6RS,

or adopted only selected parts of it.

In consequence, the Scheme Steering Committee decided in August 2009 to divide the standard into two separate but compatible languages -- a "small" language, suitable for educators, researchers, and users of embedded languages, focused on R5RS compatibility, and a "large" language focused on the practical needs of mainstream software development, intended to become a replacement for R6RS.

The present report describes the "small" language of that effort: therefore it cannot be considered in isolation as the successor to R6RS.

C++ should be the "small" language.  Things like vector and chrono and the like should be separate from the standard because they have nothing to do with the language.

[Nicol Bolas]

On Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges wrote:

> I don't think you have a clue what it means to certify something, or the costs involved. "It compiles" is not sufficient, q.v. "undefined behaviour".

I think I must have hurt your feelings. You're on the brink of both staw-man and ad-hominem with this one.

I apologise. I am not here to discredit you personally. I am here so that information can flow back from an enthusiastic (and pretty good) c++ user to the people who are making the decisions about the language I have chosen over all others to care about.

>> and so on. Basically a standard stackoverflow. (which is the de-facto
>> standard in consulting experts is it not?)
> No, it's not.

I respectfully submit that you're a little behind the times (which is odd, because of the two of us I am certain that I am the older). There's an entire generation of developers, in all languages, who use stack-overflow as their primary source of programming-related information. For good reason - the information is collectively sourced and instantly peer-reviewed by a massive enthusiastic community of contributors. The vast majority of c++ developers will never read the standard. They will consult SO, and get complete, annotated information delivered by knowledgable experts on the subject - with examples.

The c++ standards committee could learn a lot from this model.

SO is for asking questions and getting answers. It's specifically designed to avoid discussions, not promote them. And discussion is what you're wanting. So SO is a poor model.

> DirectX is not a good example, since it's not a standard and there's exactly one implementation by one vendor.

There are exactly 12 iterations of the library suite from the original vendor. They are all compatible. As you are well aware, I was illustrating how interfaces can successfully evolve over time.

You mention bugs. These are a symptom of there being only one implementor. Had there been a c++ standard for 3d, there would have been multiple implementors competing. There would be fewer bugs. There are examples in the wild. Ogre3D, Irrlicht, etc. All of varying quality and approaches but all with the same sensible design goal - standardise the damned interface, get rid of problematic proprietary interfaces. These libraries were born out of need. If they're needed in the real world, then the concept is needed in the standard.

> The C++ committee works around the ISO limitations and requirements just fine.

> I'll repeat what I said: the C++ standard is developed in one of the most open ways I've seen when it comes to standards, on par with IETF.

Maybe, but still not good enough. I've been in technology long enough to know that committees are not the best way to achieve progress. Boost exists only because the standard isn't good enough.

But Boost advances through committee...

> Aye.

Fantastic. We have a point of agreement. Let's work on that. Now that we agree that it's ok to bring something slightly imperfect out and refine it later, let's not delay networking, ranges, modules, executors and future continuations any longer, eh? 6 years is quite a long time to wait.

The idea that something may not be perfect is not in and of itself good enough reason to just throw anything into the standard.

There is a big difference between making a mistake and negligence. You should always attempt to avoid mistakes.

[Richard Hodges]

> SO is for asking questions and getting answers. It's specifically designed to avoid discussions, not promote them. And discussion is what you're wanting. So SO is a poor model.

SO allows many respondents to post answers to questions, along with practical, executable code. The user base then votes on the efficacy of those answers. In the vast majority of cases the best answer rises to the surface. This happens within hours or days. 

It's a fantastic model. The fact that there is no room for opinion is great - all claims are tested mercilessly. It's pure information.

It's a perfect model for defining the behaviour of new standard libraries. 

> But Boost advances through committee...

Not really, it advances through a base of volunteers who simply step up and fix or review code. There is a steering committee, and their latest decision demonstrates nicely what happens when a few people make a decision without communicating effectively with the entire user base.

When the announcement went out that the boost steering committee had decided to move from bjam to cmake, a number of long-term boost contributors and maintainers were outraged. One to the point where he simply quit.

Much of the user base had not encountered cmake and were bewildered.

For the record, I support the move, but the method was not democratic or crowdsourced, so it'll be painful.

> There is a big difference between making a mistake and negligence. You should always attempt to avoid mistakes.

Now you're just looking for things to argue about.

Since I have become so animated by what I consider to be a serious defect in std::string_view (well, actually an update to std::string as it happens), do you honestly think I am promoting negligence?

Come, come.

[Bruce Adams]

On Wednesday, 13 September 2017 17:58:40 UTC+1, Nicol Bolas wrote:

On Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges wrote:

>> and so on. Basically a standard stackoverflow. (which is the de-facto
>> standard in consulting experts is it not?)
> No, it's not.

I respectfully submit that you're a little behind the times (which is odd, because of the two of us I am certain that I am the older). There's an entire generation of developers, in all languages, who use stack-overflow as their primary source of programming-related information. For good reason - the information is collectively sourced and instantly peer-reviewed by a massive enthusiastic community of contributors. The vast majority of c++ developers will never read the standard. They will consult SO, and get complete, annotated information delivered by knowledgable experts on the subject - with examples.

The c++ standards committee could learn a lot from this model.

SO is for asking questions and getting answers. It's specifically designed to avoid discussions, not promote them. And discussion is what you're wanting. So SO is a poor model.

Rather I think changes should follow sound software engineering practices. That means issue tracking and source control are essential.

The C++ committee already has a document naming policy which seems pretty sound.

This collection of forums is reasonable for discussion.

I do see stack overflow often used for language lawyer type quesions. is this UB etc.

The addition of a wiki might lesson the need for data mining the forum for similar proposals but some volunteers would be needed to curate it.

The one thing perhaps lacking is a github project naming and locating scheme backing the documents. So that you could find PxxxxRy as e.g isocpp.org/proposals/PxxxxRy.git

Likewise it would be nice to see the current status and comments on a proposal as if PxxxxRy was a ticket.

There is an impedance mismatch as the Ry actually means revision and not all proposals warrant their own source repository.

Its common for developers to conflate source control and document control but I've yet to see a convincing document control system myself.

I don't know what model is used internally but I would guess something to a feature branch per proposal occurs when a proposal is mature enough to be merged.

[Bruce Adams]

On Wednesday, 13 September 2017 23:12:39 UTC+1, Bruce Adams wrote:

On Wednesday, 13 September 2017 17:58:40 UTC+1, Nicol Bolas wrote:

On Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges wrote:

>> and so on. Basically a standard stackoverflow. (which is the de-facto
>> standard in consulting experts is it not?)
> No, it's not.

I respectfully submit that you're a little behind the times (which is odd, because of the two of us I am certain that I am the older). There's an entire generation of developers, in all languages, who use stack-overflow as their primary source of programming-related information. For good reason - the information is collectively sourced and instantly peer-reviewed by a massive enthusiastic community of contributors. The vast majority of c++ developers will never read the standard. They will consult SO, and get complete, annotated information delivered by knowledgable experts on the subject - with examples.

The c++ standards committee could learn a lot from this model.

SO is for asking questions and getting answers. It's specifically designed to avoid discussions, not promote them. And discussion is what you're wanting. So SO is a poor model.

Rather I think changes should follow sound software engineering practices. That means issue tracking and source control are essential.

The C++ committee already has a document naming policy which seems pretty sound.

This collection of forums is reasonable for discussion.

Actually I do see the merit of scoring being applied here as it is in reddit and slashdot.

I'm not sure why but somehow these fora seem more civilised.

[Thiago Macieira]

On quarta-feira, 13 de setembro de 2017 14:57:23 PDT Richard Hodges wrote:
> > SO is for asking questions and getting answers. It's specifically

> > designed to *avoid* discussions, not promote them. And discussion is what

> > you're wanting. So SO is a poor model.
>
> SO allows many respondents to post answers to questions, along with
> practical, executable code. The user base then votes on the efficacy of
> those answers. In the vast majority of cases the best answer rises to the
> surface. This happens within hours or days.

That's a good model when there's only one objective answer and lots of
different people will just vote on the correctness of the solution. It's meant
for something that already exists and works (or is meant to work) in one
particular way.

That's the wrong model for discussion.

> It's a fantastic model. The fact that there is no room for opinion is great
> - all claims are tested mercilessly. It's pure information.
>
> It's a perfect model for defining the behaviour of new standard libraries.

No, it isn't. It would discourage discussion when something is not completely
clear-cut. It would also cause a popularity contest, since votes wouldn't be
on objective qualities, but on subjective ones.

It would be horrible for a standard to be developed like that.

In fact, do you know of *anything* that is developed via SO question&answers?

> When the announcement went out that the boost steering committee had
> decided to move from bjam to cmake, a number of long-term boost
> contributors and maintainers were outraged. One to the point where he
> simply quit.

Not commenting on the merits of the decision or even whether it was taken
correctly in this case. But there are certain decisions in Open Source
projects that would never happen unless there's s firm hand guiding it,
*precisely* because of the outrage that a vocal minority, to the detriment of
the silent majority.

> For the record, I support the move, but the method was not democratic or
> crowdsourced, so it'll be painful.

Software development is not a democracy nor a popularity contest.

> Since I have become so animated by what I consider to be a serious defect
> in std::string_view (well, actually an update to std::string as it
> happens), do you honestly think I am promoting negligence?

I don't think Nicol did. My reading is that he was commenting on the part
about we being humans and making mistakes. Mistakes will happen and this may
be one of them.

But the fact that we may make mistakes should not stop us from having a
rigorous review process. And the bar for the standard is much higher than that
of each individual implementation of the standard, which is higher than that
of other libraries not standardised.

[FrankHB1989]

在 2017年9月14日星期四 UTC+8上午12:57:00，Hyman Rosen写道：

Glad to see you mention Scheme, a notable example with unspecified evaluation order in function applications explicitly by the design of the language :)

I strongly agree the route to split out some portion of the language to reduce the maintenance cost of the specification and debates on adoption of some features.

(This is perhaps the first time I agree your point so much, though for different reasons.)

Although R7RS-small is not same to R7RS, and the industry is still waiting for R7RS-large eagerly. Such method may be still worth a try.

However, the case in C++ is far worse and has serious effects on feasibility, because:

1. You have actually no such baseline as the small language in C++ (freestanding implementations are too limited). On contrary, R5RS is quite appropriate to be a base (and it is already widely adopted) when R6RS fails.

2. The specification of C++ has already bloated very much. On contrary, RnRS(-small) always has less than a hundred pages.

3. The core language in C++ is far less flexible to be extended (compared to Scheme) by nature and for its history.

[Nicol Bolas]

On Wednesday, September 13, 2017 at 5:57:27 PM UTC-4, Richard Hodges wrote:

> SO is for asking questions and getting answers. It's specifically designed to avoid discussions, not promote them. And discussion is what you're wanting. So SO is a poor model.

SO allows many respondents to post answers to questions, along with practical, executable code. The user base then votes on the efficacy of those answers. In the vast majority of cases the best answer rises to the surface. This happens within hours or days. 

It's a fantastic model. The fact that there is no room for opinion is great - all claims are tested mercilessly. It's pure information.

It's a perfect model for defining the behaviour of new standard libraries.

... how?

Many of the libraries you're talking about are big; much larger than most SO questions or answers. Interactions between components will be complex. Just consider the networking TS, based on ASIO. How would you debate the asynchronous execution model, without affecting basically all of the other APIs in that library?

Furthermore, the idea that polling random people to decide what goes into the standard library is fundamentally terrible. We should decide what goes in there based on good design, not on the whims of random people who will upvote because someone made a joke in their post.

> But Boost advances through committee...

Not really, it advances through a base of volunteers who simply step up and fix or review code.

... what do you think the C++ standards committee is? They are a group of volunteers who simply step up and review proposals and vote on whether they should be part of the standard. How exactly is that different from Boost?

The committee is not some institution somewhere that you need to be hired into in order to join. All it takes to "join" them is showing up at a meeting.

There is a steering committee, and their latest decision demonstrates nicely what happens when a few people make a decision without communicating effectively with the entire user base.

When the announcement went out that the boost steering committee had decided to move from bjam to cmake, a number of long-term boost contributors and maintainers were outraged. One to the point where he simply quit.

Much of the user base had not encountered cmake and were bewildered.

For the record, I support the move, but the method was not democratic or crowdsourced, so it'll be painful.

> There is a big difference between making a mistake and negligence. You should always attempt to avoid mistakes.

Now you're just looking for things to argue about.

Since I have become so animated by what I consider to be a serious defect in std::string_view (well, actually an update to std::string as it happens), do you honestly think I am promoting negligence?

Come, come.

Well, you said this: "let's not delay networking, ranges, modules, executors and future continuations any longer, eh?". That statement suggests that you feel the "delay" in these things is not due to design issues or substantive problems, but due to those picky, Ivory Tower Intellectual types who want to argue about whether pointer arithmetic is legal rather than fixing substantive issues.

If we had thrown Ranges TS in after the first iteration, it would have been very bad. Why? Because the first version of Ranges TS used iterator pairs. It was only later ones that went to Iterator/Sentinel pairs. That is a substantial improvement (one that required a minor language change to the range-based for system), and it's not one you can fix after the fact without lots and lots of pain.

By "delaying", by doing due diligence in getting the design solid and stable, we get a much better feature. The kind of thinking that says "adopt now, fix it later" leads to negligence. It leads to you just rubber-stamping whatever someoen regurgitates at you, simply because you figure if there are any problems, you can fix them later.

The committee's current approach of making sure that proposals are reasonably solid before incorporating them into the standard is a good thing.

[Hyman Rosen]

On Thu, Sep 14, 2017 at 6:54 AM, FrankHB1989 <frank...@gmail.com> wrote:

Glad to see you mention Scheme, a notable example with unspecified evaluation order in function applications explicitly by the design of the language :)

:-)

Of course in Scheme you generally don't have expressions with side effects, so the order of evaluation doesn't matter as much.
You also don't have undefined behavior based on the argument expressions, nor resource leaks from partial or interleaved argument evaluation.

Common Lisp does have left-to-right evaluation. <https://books.google.com/books?id=FYoOIWuoXUIC&pg=PA132>

Given that Lisp programming very often involves macros that rewrite source code into plain Lisp, either the macros have to be very careful to preserve the order as written, or the language can just punt and not care about the order.

[Richard Hodges]

> Many of the libraries you're talking about are big; much larger than most SO questions or answers.... etc

This is reducto ad absurdum.

The general model of SO is that:

1. it is easily accessible by everyone, without leaving their cubicle.

2. it encourages collaboration.

3. feedback on ideas and solutions is fast, and ruthless and based on the wide experience of participants.

4. in the main, only good, evidence-based answers (read: proposals and revisions) get high numbers of votes. The votes (say, beyond 10) are a strong indication of a strong answer (read say,  100 and strong proposal).

5. did I mention that participation is easy and quick? No need for trips to conferences half way around the world. Just an exchange of ideas and good, collaborative, evolving decision-making.

If this implicit-conversion-of-string-to-string_view had been posted on a public forum, with people given the opportunity to vote on the reasons for and against, I expect we'd have had an even split of people who think the convenience is worth the danger, and people who think the danger is an unnecessary carbuncle. That would have been an excellent indication that it needs to be rethought, and a better solution provided.

If you'd have asked me or my colleagues 3 years ago (or whenever it was) whether there should be an implicit conversion, the answer would have been as unequivocal then as it is now - we think implicit conversions to dangling pointers are a /ridiculous idea/ and we'd have said as much. In public, and in time. 

[Ville Voutilainen]

On 14 September 2017 at 19:37, Hyman Rosen <hyman...@gmail.com> wrote:
> Common Lisp does have left-to-right evaluation.
> <https://books.google.com/books?id=FYoOIWuoXUIC&pg=PA132>

Yeah, except when it doesn't like in LET and DO, which is why it has
LET* and DO*. In contrast,
PSETQ and PSETF are not strictly left-to-right, whereas their prettier
versions SETQ and SETF are.

[barry....@gmail.com]

On Thursday, September 14, 2017 at 11:48:03 AM UTC-5, Richard Hodges wrote:

> Many of the libraries you're talking about are big; much larger than most SO questions or answers.... etc

This is reducto ad absurdum.

The general model of SO is that:

1. it is easily accessible by everyone, without leaving their cubicle.

2. it encourages collaboration.

3. feedback on ideas and solutions is fast, and ruthless and based on the wide experience of participants.

4. in the main, only good, evidence-based answers (read: proposals and revisions) get high numbers of votes. The votes (say, beyond 10) are a strong indication of a strong answer (read say,  100 and strong proposal).

5. did I mention that participation is easy and quick? No need for trips to conferences half way around the world. Just an exchange of ideas and good, collaborative, evolving decision-making.

StackOverflow is an objectively terrible model for standards proposals - it is very much structured against discussion. This is why comment threads get removed all the time - because that's not what comments are for. Your point (3) totally misses the mark. Feedback on specific questions that have clear, concise answers is fast and valuable. But feedback on broad questions or opinion-based questions is: vote-to-close. Standards proposal discussions fall into the second category. 

Moreover, anonymous internet voting is a bad model for deciding what to do with the C++ standard. With standards discussions, it's often just as meaningful why people vote for or against an idea as to what the resulting "score" of the idea is. SO doesn't allow for that either.

And I'm a guy who spends an unreasonably, and frankly disturbingly, large amount of time on SO answering questions - it's not that I think the site is bad in general or doesn't provide value.

[Richard Hodges]

> But feedback on broad questions or opinion-based questions is: vote-to-close. Standards proposal discussions fall into the second category. 

There is no reason people could not vote on opinions and demonstrations of new standard functionality, 

Everyone in this thread seems to take everything absolutely literally. Too much time with code perhaps. :)

What I am saying is that SO is *visible*, *immediate* and *collectively sourced*. The c++ standard evolution is not.

If I were to say "it's bad to allow implicit conversion to a reference type masquerading as a value type because xxx", thousands of people could voice their agreement or not with that statement with an immediate vote, and maybe even comment or reason, which itself could be voted on. The issue could be solved decisively.

I am *not* saying "SO is an absolutely perfect fit, let's just fork the code and use that in place of a standard". 

I am saying that the model of collective participation *is* a perfect model for evolving a common set of idioms, and libraries.

--

[Ville Voutilainen]

On 14 September 2017 at 20:33, Richard Hodges <hodg...@gmail.com> wrote:
>> But feedback on broad questions or opinion-based questions is:
>> vote-to-close. Standards proposal discussions fall into the second category.
>
> There is no reason people could not vote on opinions and demonstrations of
> new standard functionality,
>
> Everyone in this thread seems to take everything absolutely literally. Too
> much time with code perhaps. :)
>
> What I am saying is that SO is *visible*, *immediate* and *collectively
> sourced*. The c++ standard evolution is not.
>
> If I were to say "it's bad to allow implicit conversion to a reference type
> masquerading as a value type because xxx", thousands of people could voice
> their agreement or not with that statement with an immediate vote, and maybe
> even comment or reason, which itself could be voted on. The issue could be
> solved decisively.
>
> I am *not* saying "SO is an absolutely perfect fit, let's just fork the code
> and use that in place of a standard".
>
> I am saying that the model of collective participation *is* a perfect model
> for evolving a common set of idioms, and libraries.

Nothing stops volunteers from trying that sort of feedback-gathering
out. But expecting that
the already-busy volunteers in the committee will just do it just
because you wish it would
not be very realistic.

[Nicol Bolas]

On Thursday, September 14, 2017 at 12:48:03 PM UTC-4, Richard Hodges wrote:

> Many of the libraries you're talking about are big; much larger than most SO questions or answers.... etc

This is reducto ad absurdum.

The general model of SO is that:

1. it is easily accessible by everyone, without leaving their cubicle.

Low barriers to entry are not a priori a good thing.

 

2. it encourages collaboration.

No, it doesn't. Indeed, collaboration is explicitly discouraged by the Stack Overflow model.

Consider a Stack Exchange site like the RPG site. Do you see people using it to design an RPG? No; that sort of thing is explicitly discouraged.

The design of the SE model is that there's 1 question, many answers, and zero discussion between them. If someone makes a proposal, and you think there's a problem, and someone else thinks there's a problem with your reasoning, there's no way to address that without having a discussion in the comments. Which is something that is to be avoided.

3. feedback on ideas and solutions is fast, and ruthless and based on the wide experience of participants.

Speed is based solely on the fact that there are a lot of participants on the site. You have to make it popular before "fast" can happen.

 

4. in the main, only good, evidence-based answers (read: proposals and revisions) get high numbers of votes. The votes (say, beyond 10) are a strong indication of a strong answer (read say,  100 and strong proposal).

... really? You must not have been around during SO's more permissive days. There are lots of popular-but-terrible notions out there, and they will be upvoted over more considered design.

The way modern, objective SO voting works out is very different from early, subjective SO voting.

5. did I mention that participation is easy and quick? No need for trips to conferences half way around the world. Just an exchange of ideas and good, collaborative, evolving decision-making.

See #1.

If this implicit-conversion-of-string-to-string_view had been posted on a public forum, with people given the opportunity to vote on the reasons for and against, I expect we'd have had an even split of people who think the convenience is worth the danger, and people who think the danger is an unnecessary carbuncle. That would have been an excellent indication that it needs to be rethought, and a better solution provided.

No, it would not. It would simply tell you what different people upvote.

Good design is not a matter of popular opinion.

[Richard Hodges]

OK guys, you win.

It's a nice cosy little club and everyone else is wrong. I get it.

c++ will tootle along getting nowhere.

6 years is a perfectly acceptable time to wait to not get a networking library.

Happy?

[Nicol Bolas]

On Thursday, September 14, 2017 at 1:33:32 PM UTC-4, Richard Hodges wrote:

> But feedback on broad questions or opinion-based questions is: vote-to-close. Standards proposal discussions fall into the second category. 

There is no reason people could not vote on opinions and demonstrations of new standard functionality, 

I have been on SO for years. The reason opinion based questions are closed, rather than having opinionated answers vie for dominance via voting, is because it does not work. They tried it. Twice. It didn't work.

It produced lots of highly-upvoted trash. It encouraged discussion and debate in comments. And so forth. This was proven to be decidedly non-functional, from the standpoint of producing real, actionable information.

Everyone in this thread seems to take everything absolutely literally. Too much time with code perhaps. :)

What I am saying is that SO is *visible*, *immediate* and *collectively sourced*. The c++ standard evolution is not.

The standards process is somewhat visible: each proposal is posted online in an easily accessible formula.

The standards process not being "immediate" is actually a good thing. It allows proposals to be considered and revised before wasting people's time with half-baked ideas.

Collective groups can make proposals as it currently stands. They need someone to go to meetings to push them forward, but if a group wants to put something together, they can.

What the committee doesn't do is consider all opinions equal. Nor do they give primacy to what is popular.

If I were to say "it's bad to allow implicit conversion to a reference type masquerading as a value type because xxx", thousands of people could voice their agreement or not with that statement with an immediate vote, and maybe even comment or reason, which itself could be voted on. The issue could be solved decisively.

How would that solve the issue? Good design is not a matter of popular opinion.

I would not take votes as some form of proof for an idea.

I am *not* saying "SO is an absolutely perfect fit, let's just fork the code and use that in place of a standard". 

I am saying that the model of collective participation *is* a perfect model for evolving a common set of idioms, and libraries.

A small cloister of people can develop a good API. Large bodies of people however cannot.

Let's take an example: Vulkan. It was created by a small cloister of people with intimate hardware knowledge and expertise.

The render pass system of Vulkan exists for the sole purpose of allowing tile-based renderers to have reasonable performance, to make code that performs badly on TBRs obvious at the API level that it will perform badly on them.

And yet, there are a number of developers who don't care about TBRs, because they develop only for desktop GPUs. To them, the render pass system is merely an annoyance, a silly API dance they have to do to get what they want.

Some of them would totally upvote a suggestion that Vulkan abandon the render pass system in favor of a more traditional model, regardless of how that would affect Vulkan's mobile users. Why? Because they're voting for what's good for themselves, not what is good for the API.

I do not trust good design principles to manifest themselves based on anonymous voting patterns.

[Nicol Bolas]

On Thursday, September 14, 2017 at 3:10:13 PM UTC-4, Richard Hodges wrote:

OK guys, you win.

It's a nice cosy little club and everyone else is wrong. I get it.

This kind of attitude completely undermines any valid point you might have. You continue to act like the committee is some hidden-away thing, despite the fact that participation by people is actively encouraged, that proposals are publicly available, and so forth. It's not a "cosy little club" if anyone can join.

Stop arguing against a strawman of reality, and start dealing with it as it exists.

Similarly, there's this notion that if your idea for how to improve things isn't a good one, then that means we think everything is perfectly fine. I for one would certainly like to see some changes to the committee's process.

But that doesn't mean I would support your suggestion.

c++ will tootle along getting nowhere.

6 years is a perfectly acceptable time to wait to not get a networking library.

Because God knows we've gotten nothing else done in that 6 years. And certainly, dropping everything else and focusing exclusively on networking would have made C++ a much better language.

Also, the Networking library is a published TS.

Tilting at windmills only makes you look deranged.

Happy?

With what? Your problem seems to be inappropriate expectations. That the committee should chrun out standards based on your personal whims rather than the good of the language.

Stop expecting more than is actually likely to happen, and you won't have this problem.

Indeed, I think the #1 problem with such expectations is that committee members love laying out grand plans for the future. If they would just stop doing that, then people wouldn't be disappointed when they don't pan out.

[Ville Voutilainen]

On 14 September 2017 at 22:35, Nicol Bolas <jmck...@gmail.com> wrote:
> Indeed, I think the #1 problem with such expectations is that committee
> members love laying out grand plans for the future. If they would just stop
> doing that, then people wouldn't be disappointed when they don't pan out.

Fairly few of them do. Some prominent ones suggest such plans. I wrote
a bold suggestion
for one, but it was never even polled to be accepted.

Complaining on this forum and doing nothing else accomplishes nothing.
I might point out
that there's been an implementation of experimental::string_view in
libstdc++ since 2013,
so if you have bothered to install any linux distribution since 2014,
you have had it in your
system compiler. And there are online compilers that can be used for
trying out such features,
so you (in the general sense, not the sender I'm replying to) don't
even need to install
anything if you happen to have a magical tool called a "web browser".
Claiming that you
haven't been able to try string_view out is a lie.

[Richard Hodges]

> Indeed, I think the #1 problem with such expectations is that committee
> members love laying out grand plans for the future. If they would just stop
> doing that, then people wouldn't be disappointed when they don't pan out.

Had these grand plans not been laid out by Herb in 2011, I would have switched from c++ to java at that point. It was these plans, coupled with the Great Leap Forward of c++11 that convinced me that c++ wasn't a dead duck.

I was keen to continue with c++ because I like the low level nature of it and c++11's ability to write "provably correct at compile time" programs, with no need for null pointer checks. I was convinced to stay with c++ for my new (and continuing) cross-platform project.

In hindsight, much as I loathe garbage collectors and nullable references, and like the low level nature of c++, the positive influence of Herb Sutter on the committee seems to have been eviscerated by a deep sycophancy to the status quo.

Damn shame.

[Nevin Liber]

On Thu, Sep 14, 2017 at 2:48 PM, Ville Voutilainen <ville.vo...@gmail.com> wrote:

Complaining on this forum and doing nothing else accomplishes nothing.
I might point out
that there's been an implementation of experimental::string_view in
libstdc++ since 2013,

And Boost added string_ref based on the original proposal in 2013 (Boost 1.53).  <http://www.boost.org/doc/libs/1_53_0/libs/utility/doc/html/string_ref.html>

 

Claiming that you
haven't been able to try string_view out is a lie.

+1

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[inkwizyt...@gmail.com]

On Thursday, September 14, 2017 at 6:48:03 PM UTC+2, Richard Hodges wrote:

> Many of the libraries you're talking about are big; much larger than most SO questions or answers.... etc

This is reducto ad absurdum.

The general model of SO is that:

1. it is easily accessible by everyone, without leaving their cubicle.

2. it encourages collaboration.

3. feedback on ideas and solutions is fast, and ruthless and based on the wide experience of participants.

4. in the main, only good, evidence-based answers (read: proposals and revisions) get high numbers of votes. The votes (say, beyond 10) are a strong indication of a strong answer (read say,  100 and strong proposal).

5. did I mention that participation is easy and quick? No need for trips to conferences half way around the world. Just an exchange of ideas and good, collaborative, evolving decision-making.

 <Trollmode on>

You first post get ten down votes (count people who disagree with you), we can stop this discussion because we only discuss there positive posts.

I agree, SO system is so great :)

[Bruce Adams]

On Thursday, 14 September 2017 17:16:49 UTC+1, Nicol Bolas wrote:

On Wednesday, September 13, 2017 at 5:57:27 PM UTC-4, Richard Hodges wrote:

> SO is for asking questions and getting answers. It's specifically designed to avoid discussions, not promote them. And discussion is what you're wanting. So SO is a poor model.

SO allows many respondents to post answers to questions, along with practical, executable code. The user base then votes on the efficacy of those answers. In the vast majority of cases the best answer rises to the surface. This happens within hours or days. 

It's a fantastic model. The fact that there is no room for opinion is great - all claims are tested mercilessly. It's pure information.

It's a perfect model for defining the behaviour of new standard libraries.

... how?

Many of the libraries you're talking about are big; much larger than most SO questions or answers. Interactions between components will be complex. Just consider the networking TS, based on ASIO. How would you debate the asynchronous execution model, without affecting basically all of the other APIs in that library?

Furthermore, the idea that polling random people to decide what goes into the standard library is fundamentally terrible. We should decide what goes in there based on good design, not on the whims of random people who will upvote because someone made a joke in their post.

+1

Sorry couldn't resist it.

[Ricardo Fabiano de Andrade]

Even though I totally disagree with Richard's tone in this discussion I do understand his frustration with the current status quo of C++. I felt like this myself in several occasions.

Despite my admiration for the members of the committee and all the effort they put in the standard, I think there's plenty of room for improvement in a few areas.

The most critical in my opinion is that the communication channel between community and committee is too narrow and therefore the feedback is insufficient.

There's no clear path for trying a new library or language features.

As example, it doesn't matter if string_view has been available for several years if no one knows about it, which purpose is it supposed to serve and how to use it.

It's very hard for someone that doesn't follow the standard to get to know about a proposal and where to try it.

The committee is counting on volunteers but there's no effort to make this need explicit. Honestly, a language complex as C++ needs all the help one can get.

On the contrary, the few channels available (this one and std proposals) are very closed (and sometimes it feels unwelcoming) to the general community.

The community gets their hands on language and library changes very late in the process.

And boost can't serve much as a test bed because the experience has been proving that once something from boost passes through the committee, a whole lot changes.

Most of the record of such changes and decisions is closed to the general community - because ISO doesn't allow that to be public in some cases.

The majority of the community is not interested in submitting proposals. The bar is too high and it's too big of a commitment.

But everyone is eager to try the "next big thing". The current process is missing all this participation.

Change is slow and corrections even slower.

The 3-year cycle is an eternity in the current environment of software development.

If what has been discussed here about string_view is really a problem it may take up to absurd 9 years to fix the standard.

3 years to confirm it was a bad idea, then 3 deprecate in the next standard, then 3 to remove on the next.

By that time Rust might have took over all native development! :-/

Worst of how much harm this can cause to the users of the language and to the several applications plagued by it, it's how bad this is for the reputation of C++.

Richard is right that all the good will and excitement brought by C++11 is being buried by what most of the community see as a bunch of bad moves on the direction of C++.

Even though I don't share this point of view, I can't change how others perceive past events.

I believe there's still time to get things right before C++ becomes the new COBOL.

Here's a few (radical?) ideas:

1) Break the standard in two - language and library - but not literaly.

Keep the 3-year cycle for language, have a much shorter (4-month / per-meeting?) cycle for library changes.

Organize a different work group for the short cycle to not drawn resources away from the main work groups.

What could be done under these short cycles:

- Fixing defect reports

- Improve on usabiliy and ease-of-use issues (example: make_unique)

- Test library-only solutions that may demand languange additions not certain to be worth

- Deprecating library features

- Remove deprecated library features

- Merging library TSs which do not require language changes

Then offload some of this work to the community.

One idea is having a centralized issue tracking where compiler and library maintainers and users could post defects or ask for improvements.

2) Stop using std::experimental and instead use std::alpha / std::beta (or anything that indicates how close such feature is to the final standard).

Companies/teams would be more comfortable adopting and testing pre-standard features.

Provide an easy to access matrix of these features but different of the current one currently on isocpp.org that only contains the proposal number and vendor/version availability it would also have:

- Synopsis of motivation

- A collection of practical examples

- A history of the decisions around the design

- Such matrix could be maintained by the community similarly as the Core Guidelines.

3) Library proposals should have standard implementations which compile in all major compilers compliant with the targeted standard.

- I am aware this is close to a de facto requirement.

- But the change is that they would be centralized in a common repository.

- Library features could target an older standard if that makes sense.

- People not able or not willing to switch to a new standard could use the standard implementation.

- A standard implementation would stop to be maintained once part of the standard.

- If modified for adhering to a subsequent standard, it's assumed to be a new proposal.

4) All the ideas above use, if you will, the "github" model for driving the work around the standard.

But there's still room for a "StackOverflow" model to gauge interest and/or indicate deficiencies in the final product.

As soon as the model above is available the parts of the library/language with more questions are either:

- The "hot" features that everyone is looking into integrating in their work.

- Or, the ones lacking documentation or too difficult to be used by the average user of the language.

- StackOverflow itself can be used, no need to reinvent the will.

Those ideas aim to drive more people to participate in the new "maintenance" work group as well in providing feedback.

They centralize the efford to make the standard happen - a single source of truth of sorts - that should be in the front page of isocpp.org.

I believe this also addresses the concerns of both the camp of "C++ evolution is sluguish" and the camp of "I can't keep up with C++".

Also, the experts are left alone to drive the evolution of the language every 3 years but they will be watched more closely by whole community involved in maintaining the current standard.

All this is suplemental to the current communities revolving around C++ such as clang, gcc, boost, etc. They would feed from the "standard" community and vice-versa.

That said, who's interested in convincing the committee and tackle this challenge? :)

[FrankHB1989]

在 2017年9月15日星期五 UTC+8上午12:37:55，Hyman Rosen写道：

Not quite. Scheme has mandatory `set!` form (or "expression type", in R7RS words) which can expose side effects. And Scheme also has `begin` form (just like comma operator in C) to explicitly express the left-to-right evaluation of expressions. So I assume it is deliberated by design. It is true that Scheme (except R6RS) does not have "undefined" behavior, but leaving the result unspecified also fall in the category you don't want.

Historically, traditional Lisp dialects have the form `progn` to evaluate expression left-to-right and return the nth result. In standard Scheme, it is called `block` before R2RS and `begin` since then.

Some other Lisp-like derivations can have similar design, even when the mutation operations (which have side effects) are not mandated. In fact, this can even make the overall evaluation rules much simpler. For instance, the Kernel language has rules similar to Scheme in a more general way by a single evaluation algorithm over all forms, including evaluation of both application and "special" forms. It also has a `$sequence` operative as analog of Scheme's `begin`, derived from primitive operators which does not rely on left-to-right evaluation order at all. This also shows the left-to-right rule is not necessarily to be in the core language, even users do need to use it.

Given the fact that order of expression evaluation can be significant in general, it should be encouraged to be explicitly expressed that in the object language. Implicit left-to-right rules may work in many cases, but it is not a good excuse to let users forget the reason of existence of the rule. This may differ in flavors, though. But this does not make ruling out non left-to-right necessary. In fact, languages like Scheme has a mixed style. For example, body of `lambda` forms in Scheme are evaluated from left to right. Kernel implemented its `$lambda` using `$sequence`. In C, there are built-in `;` and `,` (though technically they are not quite the same, and ... ugly to specify). For users, the mixture of style is not difficult to learn. They have to know it sooner or later, unless they don't use such languages at all.

OTOH, once unsequenced operations are needed, it is very difficult to simulate it in the object language without any black magic. See formal semantic specification in appendices of RnRS for example (both R6RS's operational method and traditional RnRS denotational method fall in the "magic" category).

[Nicol Bolas]

On Thursday, September 14, 2017 at 11:43:51 PM UTC-4, Ricardo Andrade wrote:

Even though I totally disagree with Richard's tone in this discussion I do understand his frustration with the current status quo of C++. I felt like this myself in several occasions.

Despite my admiration for the members of the committee and all the effort they put in the standard, I think there's plenty of room for improvement in a few areas.

The most critical in my opinion is that the communication channel between community and committee is too narrow and therefore the feedback is insufficient.

There's no clear path for trying a new library or language features.

As example, it doesn't matter if string_view has been available for several years if no one knows about it, which purpose is it supposed to serve and how to use it.

It's very hard for someone that doesn't follow the standard to get to know about a proposal and where to try it.

"Where to try it" is not something the standards committee can deal with. The committee publishes standards, not implementations.

As for knowing about a proposal... I really don't know how much more the committee can do. There's an entire website whose sole purpose is to be where standard C++ news items happen. That website publishes the mailings, which contain all of the proposals in question.

What more do you want?

People who want to affect the language should be expected to put forth the minimal effort of paying attention to channels of information. I don't think that's asking too much.

The committee is counting on volunteers but there's no effort to make this need explicit. Honestly, a language complex as C++ needs all the help one can get.

And a language as complex as C++ needs as little of the wrong kind of help as it can get. That's really important too.

On the contrary, the few channels available (this one and std proposals) are very closed (and sometimes it feels unwelcoming) to the general community.

I'm not sure how much more open you can get by having a forum/mailing list that literally anybody can sign up to use. The forums may be well-hidden, but once you find them, they're right here.

The community gets their hands on language and library changes very late in the process.

And boost can't serve much as a test bed because the experience has been proving that once something from boost passes through the committee, a whole lot changes.

Most of the record of such changes and decisions is closed to the general community - because ISO doesn't allow that to be public in some cases.

The majority of the community is not interested in submitting proposals. The bar is too high and it's too big of a commitment.

But everyone is eager to try the "next big thing". The current process is missing all this participation.

I'm not sure how useful such participation would be. If you're not able to put together a proposal... what exactly can you do to improve the standard? Ideas are easy; it's the details that are hard. And it's the details that we need.

Again, if you want some kind of collective proposal development system, that's fine. But it still needs to lead to an actual proposal, not a bunch of ideas or functions that someone else has to cobble together into a working whole.

So what would this participation be, providing commentary on proposals? That just requires people who have actual domain knowledge to spend their time sifting through the 90% of worthless comments for the occasional nugget of genuinely useful information. That is a huge waste of time.

Change is slow and corrections even slower.

The 3-year cycle is an eternity in the current environment of software development.

If what has been discussed here about string_view is really a problem it may take up to absurd 9 years to fix the standard.

3 years to confirm it was a bad idea, then 3 deprecate in the next standard, then 3 to remove on the next.

By that time Rust might have took over all native development! :-/

Worst of how much harm this can cause to the users of the language and to the several applications plagued by it, it's how bad this is for the reputation of C++.

Richard is right that all the good will and excitement brought by C++11 is being buried by what most of the community see as a bunch of bad moves on the direction of C++.

Even though I don't share this point of view, I can't change how others perceive past events.

I believe there's still time to get things right before C++ becomes the new COBOL.

Here's a few (radical?) ideas:

1) Break the standard in two - language and library - but not literaly.

Keep the 3-year cycle for language, have a much shorter (4-month / per-meeting?) cycle for library changes.

How would that be anything other than a "literal" breaking of the standard into two? You can't release a new version of part of a document.

Organize a different work group for the short cycle to not drawn resources away from the main work groups.

What could be done under these short cycles:

- Fixing defect reports

- Improve on usabiliy and ease-of-use issues (example: make_unique)

- Test library-only solutions that may demand languange additions not certain to be worth

- Deprecating library features

- Remove deprecated library features

OK, let's wind the clocks back to 2011. C++11 is about to be published, and you're going to deprecate `auto_ptr`. And this time, you're deprecating it with the expressed idea of replacing it with `unique_ptr`. So you're serious about it.

Now, forget everything about how long it takes to publish another standard. If you had to pick a year, what year would you say "OK, everyone's had enough time to switch to `unique_ptr`, so we're eliminating `auto_ptr`"?

I submit that no year before 2016 is workable. You need to be fully aware of just how much C++ code exists out there. And just how much of it needs to compile and yet isn't being actively maintained.

And we're talking about a drop in replacement here, where any differences between `auto_ptr` and `unique_ptr` will be obvious, noisy, and quickly resolved. And some people still complain after six years of warning.

To remove a more widely used feature would require at least as much time if not more. So I fail to see how the 3 year period is a problem. You cannot practically remove features that people are using like that. Not if you want a language that works.

 

- Merging library TSs which do not require language changes

Then offload some of this work to the community.

You cannot publish an international standard based on random people on the Internet.

One idea is having a centralized issue tracking where compiler and library maintainers and users could post defects or ask for improvements.

2) Stop using std::experimental and instead use std::alpha / std::beta (or anything that indicates how close such feature is to the final standard).

Companies/teams would be more comfortable adopting and testing pre-standard features.

Provide an easy to access matrix of these features but different of the current one currently on isocpp.org that only contains the proposal number and vendor/version availability it would also have:

- Synopsis of motivation

- A collection of practical examples

- A history of the decisions around the design

- Such matrix could be maintained by the community similarly as the Core Guidelines.

There's no way that's going to fit into a "matrix".

Consider `std::variant`. That proposal went through a huge number of changes. And the proposals kept extensive notes documenting not only each change, but the committee votes responsible for it. The history section for some of those revisions required pages. You can't fit all of that into a "matrix".

3) Library proposals should have standard implementations which compile in all major compilers compliant with the targeted standard.

- I am aware this is close to a de facto requirement.

- But the change is that they would be centralized in a common repository.

- Library features could target an older standard if that makes sense.

- People not able or not willing to switch to a new standard could use the standard implementation.

- A standard implementation would stop to be maintained once part of the standard.

- If modified for adhering to a subsequent standard, it's assumed to be a new proposal.

4) All the ideas above use, if you will, the "github" model for driving the work around the standard.

But there's still room for a "StackOverflow" model to gauge interest and/or indicate deficiencies in the final product.

As soon as the model above is available the parts of the library/language with more questions are either:

- The "hot" features that everyone is looking into integrating in their work.

- Or, the ones lacking documentation or too difficult to be used by the average user of the language.

- StackOverflow itself can be used, no need to reinvent the will.

Those ideas aim to drive more people to participate in the new "maintenance" work group as well in providing feedback.

Again, what kind of "participation" are you talking about? Before you can start proposing solutions, you need to explain how, in your ideal world, people would be materially contributing to C++.

 

They centralize the efford to make the standard happen - a single source of truth of sorts - that should be in the front page of isocpp.org.

I believe this also addresses the concerns of both the camp of "C++ evolution is sluguish" and the camp of "I can't keep up with C++".

Also, the experts are left alone to drive the evolution of the language every 3 years but they will be watched more closely by whole community involved in maintaining the current standard.

All this is suplemental to the current communities revolving around C++ such as clang, gcc, boost, etc. They would feed from the "standard" community and vice-versa.

That said, who's interested in convincing the committee and tackle this challenge? :)

Fork Clang and libc++, and go start your own language split from the needs of an ISO process. You can build whatever process you want for it.

[Richard Hodges]

> Fork Clang and libc++, and go start your own language split from the needs of an ISO process. You can build whatever process you want for it.

Should I read this as, "go make your own language, we don't want to hear your concerns about the one you've been using for a quarter of a century. It's ours."?

It reads a little partisan I'm afraid.

It strengthens my concern that this forum is an echo chamber for believers, and that dissenters are unwelcome.

[Bruce Adams]

On Friday, 15 September 2017 06:10:45 UTC+1, Nicol Bolas wrote:

On Thursday, September 14, 2017 at 11:43:51 PM UTC-4, Ricardo Andrade wrote:

Even though I totally disagree with Richard's tone in this discussion I do understand his frustration with the current status quo of C++. I felt like this myself in several occasions.

Despite my admiration for the members of the committee and all the effort they put in the standard, I think there's plenty of room for improvement in a few areas.

The most critical in my opinion is that the communication channel between community and committee is too narrow and therefore the feedback is insufficient.

There's no clear path for trying a new library or language features.

As example, it doesn't matter if string_view has been available for several years if no one knows about it, which purpose is it supposed to serve and how to use it.

It's very hard for someone that doesn't follow the standard to get to know about a proposal and where to try it.

"Where to try it" is not something the standards committee can deal with. The committee publishes standards, not implementations.

True but many developments demand implementation experience. The conscientious proposers put their implementations on an open source repository somewhere

and reference it in the proposal. There is an argument that they could belong together in the same incubator. Boost is no longer an ideal incubator as it has

a life of its own as an independent library though it is still ideal for some ideas.

I think perhaps  source should NOT belong initially in an incubator owned by the ISO organisation. Because there are many proposals and few get chosen.

It might be that after the first iteration or so when its clear the proposal is desirable but not mature that it could then move to the ISO incubator.

I don't think that need be any more complex than having an organisation on github called iso c++ and simply moving the 'main' repo there. That would also be good

if a proposal gets orphaned by the original proposers moving on.

As for knowing about a proposal... I really don't know how much more the committee can do. There's an entire website whose sole purpose is to be where standard C++ news items happen. That website publishes the mailings, which contain all of the proposals in question.

What more do you want?

People who want to affect the language should be expected to put forth the minimal effort of paying attention to channels of information. I don't think that's asking too much.

Absolutely.

The committee is counting on volunteers but there's no effort to make this need explicit. Honestly, a language complex as C++ needs all the help one can get.

And a language as complex as C++ needs as little of the wrong kind of help as it can get. That's really important too.

Yes. This about filtering out low quality ideas from people who have not thought them through. This is one place where a stack overflow model might sort of makes sense.

Bad ideas need to get down voted quickly an idea good enough to get upvoted based on merit not just popularity. Merit is typically an AI hard problem though.

On the contrary, the few channels available (this one and std proposals) are very closed (and sometimes it feels unwelcoming) to the general community.

I'm not sure how much more open you can get by having a forum/mailing list that literally anybody can sign up to use. The forums may be well-hidden, but once you find them, they're right here.

The community gets their hands on language and library changes very late in the process.

And boost can't serve much as a test bed because the experience has been proving that once something from boost passes through the committee, a whole lot changes.

Most of the record of such changes and decisions is closed to the general community - because ISO doesn't allow that to be public in some cases.

The majority of the community is not interested in submitting proposals. The bar is too high and it's too big of a commitment.

But everyone is eager to try the "next big thing". The current process is missing all this participation.

I'm not sure how useful such participation would be. If you're not able to put together a proposal... what exactly can you do to improve the standard? Ideas are easy; it's the details that are hard. And it's the details that we need.

I think the point was getting community feedback on the details. Like implementation experience with a TS. Beta testers don't develop the product but they use it and their feedback helps improve it.

But you're right its the details that are hard and where resources are limited. Perhaps expanding on articles like the life-cycle of proposal (https://isocpp.org/std/submit-a-proposal) would help act as training materials.

"Critical Thinking for would-be language designers 101".

 

Here's a few (radical?) ideas:

1) Break the standard in two - language and library - but not literaly.

Keep the 3-year cycle for language, have a much shorter (4-month / per-meeting?) cycle for library changes.

How would that be anything other than a "literal" breaking of the standard into two? You can't release a new version of part of a document.

Don't we already have different working groups for the core language, the libraries and other special interest areas?

Isn't that enough?

 

One idea is having a centralized issue tracking where compiler and library maintainers and users could post defects or ask for improvements.

2) Stop using std::experimental and instead use std::alpha / std::beta (or anything that indicates how close such feature is to the final standard).

Companies/teams would be more comfortable adopting and testing pre-standard features.

Provide an easy to access matrix of these features but different of the current one currently on isocpp.org that only contains the proposal number and vendor/version availability it would also have:

- Synopsis of motivation

- A collection of practical examples

- A history of the decisions around the design

- Such matrix could be maintained by the community similarly as the Core Guidelines.

There's no way that's going to fit into a "matrix".

Consider `std::variant`. That proposal went through a huge number of changes. And the proposals kept extensive notes documenting not only each change, but the committee votes responsible for it. The history section for some of those revisions required pages. You can't fit all of that into a "matrix".

This to my mind is where issue trackers and wiki's fit in.

An issue has commentary and ultimately is resolved. It needs to be actionable as do most proposal documents.

A wiki page on the other hand would describe the current status.

If you have a wiki which accepts comments (for example confluence) the comments added to the wiki could be treated a bit like issues.

A comment would be resolved by updating the wiki to reflect the most up to date information.

"page: proposal to add foobar.

implementation notes:

foobar works like this.

link to github repo

link to issue tracker.

comment:

  If you do foobar don't you have to worry about snafu?"

becomes:

"page: proposal to add foobar.

implementation notes:

foobar works like this.

snafu is accounted for by zuul.

link to github repo

link to issue tracker.

comment deleted / marked as resolved."

You still need a reasonable high bar to comments and higher still for issues to deal with the signal to noise problem.

> Fork Clang and libc++, and go start your own language split from the needs of an ISO process. You can build whatever process you want for it.

That is a valid model for new proposals. Its definitely been a great help for concepts and modules.

New languages also drive things forward. C++ has learned from python, D and many others as they have learned from C++.

[Bruce Adams]

On Friday, 15 September 2017 09:38:08 UTC+1, Richard Hodges wrote:

> Fork Clang and libc++, and go start your own language split from the needs of an ISO process. You can build whatever process you want for it.

Should I read this as, "go make your own language, we don't want to hear your concerns about the one you've been using for a quarter of a century. It's ours."?

It reads a little partisan I'm afraid.

It strengthens my concern that this forum is an echo chamber for believers, and that dissenters are unwelcome.

Don't be ridiculous. That this debate exists at all and has some sensible contributions proves that this is not the case.

[Matthew Woehlke]

On 2017-09-14 23:43, Ricardo Fabiano de Andrade wrote:
> 1) Break the standard in two - language and library - but not literaly.
> Keep the 3-year cycle for language, have a much shorter (4-month /
> per-meeting?) cycle for library changes.

I just can't see this happening. Already, implementations lag behind the
standard, sometimes for years. Even at a three-year cycle, we're seeing
implementations struggling to have full support for the previous
standard before the next one is released.

There is also a VERY high bar for backwards compatibility. This is a
mixed blessing. On the one hand, it's important, because, unlike
stand-alone libraries, it is more difficult to use an older version of
the standard library. One can hope that their vendor develops the
standard library in a way that allows it to be used in compatibility
mode, but not all vendors do so (VS in particular comes to mind).

We need either the current, slow-to-change, long-term compatibility
model, or we need a better ecosystem of "common", granular, and
easy-to-obtain libraries more like the Python model. Both approaches
have disadvantages, which are often inherent to the problems they try to
solve.

> 2) Stop using std::experimental and instead use std::alpha / std::beta (or
> anything that indicates how close such feature is to the final standard).
> Companies/teams would be more comfortable adopting and testing pre-standard
> features.

Do you have any evidence to support this?

In my experience, the reason developers are slow to adopt new features
is usually need to support older compilers. One project I work on has
only recently moved to full C++11... 5-6 years after that standard was
published. We've only been able to do so because a) we "finally" dropped
support for Red Hat 6, and b) VS2015 finally has decent support for that
standard.

This situation may improve in the future, but if it does, it won't have
anything to do with naming conventions.

> 3) Library proposals should have standard implementations which compile in
> all major compilers compliant with the targeted standard.
> - I am aware this is close to a de facto requirement.
> - But the change is that they would be centralized in a common repository.

So, basically... you want to eliminate multiple standard library
implementations. There are advantages to that. There are also drawbacks.
You'd need an acceptable license. You'd need folks to agree to allow
compiler-specific code. You'd also need a solution for embedded
platforms, for which the full standard library is both unnecessary and
too big.

On the other hand, if we went that route, we might as well all just use
something like Qt. Per above, by the time you solve *all* the problems
that moving in this direction entails, you've basically moved from the
current C++ standard library approach to something much more like Python.

--
Matthew

[Richard Hodges]

> On the other hand, if we went that route, we might as well all just use
> something like Qt. Per above, by the time you solve *all* the problems
> that moving in this direction entails, you've basically moved from the
> current C++ standard library approach to something much more like Python.

This path leads to my current position, wherein alas...

* the c++ standard is useful to describe language behaviour and pretty much nothing else.

* boost (or Qt if you're that way inclined) is the actual de-facto c++ standard utility library, with the added advantage that it's modular,

* which if you use boost::asio, as I do, means that openssl is the standard security library. (blegh!)

* graphics and human interaction in c++ is always going to be a muddle because of zero official standardisation, which means fewer and fewer new projects in that domain will use c++.

leading to...

* c++ is in reality a hobby tool. If one counts the cost of software development, it is irrational to allow c++ to be used in the organisation.

pre-empting: "but, but, performance, close to the machine etc".

People who pay the wages of software engineers are more concerned with output per engineer. Adding another core to the cluster to make up for a minuscule loss of performance due to double-indirection of pointers or whatnot is way cheaper than paying someone to play around trying to get open source graphics libraries or crypto libraries to compile.

The only way to increase the productivity of a c++ engineer to match that of a Java or Javascript dev is to give him comparably useful, standard, tools.

It all looked so much brighter back in 2011.

Oh well.

 for me, boost is the standard

[Ricardo Fabiano de Andrade]

On Fri, Sep 15, 2017 at 12:10 AM, Nicol Bolas <jmck...@gmail.com> wrote:

On Thursday, September 14, 2017 at 11:43:51 PM UTC-4, Ricardo Andrade wrote:

Even though I totally disagree with Richard's tone in this discussion I do understand his frustration with the current status quo of C++. I felt like this myself in several occasions.

Despite my admiration for the members of the committee and all the effort they put in the standard, I think there's plenty of room for improvement in a few areas.

The most critical in my opinion is that the communication channel between community and committee is too narrow and therefore the feedback is insufficient.

There's no clear path for trying a new library or language features.

As example, it doesn't matter if string_view has been available for several years if no one knows about it, which purpose is it supposed to serve and how to use it.

It's very hard for someone that doesn't follow the standard to get to know about a proposal and where to try it.

"Where to try it" is not something the standards committee can deal with. The committee publishes standards, not implementations.

Which is very narrow way of thinking. You put a lot of effort on something for a target audience but they are never going to try it. Or worst, when they try, they hate it.

That's why I am suggesting ways of bringing the community to more actively participate, to bridge this gap.

 

As for knowing about a proposal... I really don't know how much more the committee can do. There's an entire website whose sole purpose is to be where standard C++ news items happen. That website publishes the mailings, which contain all of the proposals in question.

What more do you want?

Knowing where to find the implementations of a proposal so I can try, know about the design decisions around a proposal so I can decide for myself if in favor or against it... and more importantly IN A SINGLE PLACE.

Saying that std proposals mail list is this place is a extremely short sighted view of what could be done. To begin with, some proposals skip it entirely, a lot of proposals go to SG14 mail list instead...

 

People who want to affect the language should be expected to put forth the minimal effort of paying attention to channels of information. I don't think that's asking too much.

Yes, it is. Judging by the time you expend here and on std proposals I assume your metric of "minimal" is different of most people.

Expecting religious dedication is the current state and it is showing its limits.

If we could harness every idle minute of the entire C++ community huge things could be done.

 

The committee is counting on volunteers but there's no effort to make this need explicit. Honestly, a language complex as C++ needs all the help one can get.

And a language as complex as C++ needs as little of the wrong kind of help as it can get. That's really important too.

First, there's no wrong kind of help. There's a misguided effort. Again, communication is important to avoid that.

Second, I am not proposing a direct democracy kind of participation.

My idea is:

- The community drives the new work group working on minor versions standards.

- The new work group acts as a filter and as a guide for the community.

- The feedback is taken to other work groups working on the major version of the standard.

Finally, is committee open or not? You are contradicting your own arguments.

 

On the contrary, the few channels available (this one and std proposals) are very closed (and sometimes it feels unwelcoming) to the general community.

I'm not sure how much more open you can get by having a forum/mailing list that literally anybody can sign up to use. The forums may be well-hidden, but once you find them, they're right here.

I am sure it can get more open and that's my proposal.

"The forums may be well-hidden" = wrong!

What are you hiding from? Uncomfortable questions? Challenged assumptions?

Yes, I intend to pop your bubble!

 

The community gets their hands on language and library changes very late in the process.

And boost can't serve much as a test bed because the experience has been proving that once something from boost passes through the committee, a whole lot changes.

Most of the record of such changes and decisions is closed to the general community - because ISO doesn't allow that to be public in some cases.

The majority of the community is not interested in submitting proposals. The bar is too high and it's too big of a commitment.

But everyone is eager to try the "next big thing". The current process is missing all this participation.

I'm not sure how useful such participation would be. If you're not able to put together a proposal... what exactly can you do to improve the standard? Ideas are easy; it's the details that are hard. And it's the details that we need.

My testing the proposals in the real world. Isn't that the idea behind a TS anyway?

 

Again, if you want some kind of collective proposal development system, that's fine. But it still needs to lead to an actual proposal, not a bunch of ideas or functions that someone else has to cobble together into a working whole.

Agreed. I am not proposing a change in the process. Just more ways to drive the process and provide feedback.

 

So what would this participation be, providing commentary on proposals? That just requires people who have actual domain knowledge to spend their time sifting through the 90% of worthless comments for the occasional nugget of genuinely useful information. That is a huge waste of time.

You just said that the C++ community is incapable of using the resulting work of the committee.

That by itself is problem.

Again, there must be a filter - a moderator - capable of both understand the community feedback and take it to the committee.

I agree that forcing the people responsible for proposals to go over hundreds of emails is counter productive, even though that's the boost model.

 

Change is slow and corrections even slower.

The 3-year cycle is an eternity in the current environment of software development.

If what has been discussed here about string_view is really a problem it may take up to absurd 9 years to fix the standard.

3 years to confirm it was a bad idea, then 3 deprecate in the next standard, then 3 to remove on the next.

By that time Rust might have took over all native development! :-/

Worst of how much harm this can cause to the users of the language and to the several applications plagued by it, it's how bad this is for the reputation of C++.

Richard is right that all the good will and excitement brought by C++11 is being buried by what most of the community see as a bunch of bad moves on the direction of C++.

Even though I don't share this point of view, I can't change how others perceive past events.

I believe there's still time to get things right before C++ becomes the new COBOL.

Here's a few (radical?) ideas:

1) Break the standard in two - language and library - but not literaly.

Keep the 3-year cycle for language, have a much shorter (4-month / per-meeting?) cycle for library changes.

How would that be anything other than a "literal" breaking of the standard into two? You can't release a new version of part of a document.

Explanation below. Never said anything about putting language and library in separated documents.

 

Organize a different work group for the short cycle to not drawn resources away from the main work groups.

What could be done under these short cycles:

- Fixing defect reports

- Improve on usabiliy and ease-of-use issues (example: make_unique)

- Test library-only solutions that may demand languange additions not certain to be worth

- Deprecating library features

- Remove deprecated library features

OK, let's wind the clocks back to 2011. C++11 is about to be published, and you're going to deprecate `auto_ptr`. And this time, you're deprecating it with the expressed idea of replacing it with `unique_ptr`. So you're serious about it.

I can't do anything about the past but let's go with your arguments...

 

Now, forget everything about how long it takes to publish another standard. If you had to pick a year, what year would you say "OK, everyone's had enough time to switch to `unique_ptr`, so we're eliminating `auto_ptr`"?

The more you put in the standard the longer it takes... the longer something stays in the standard, the more it gets used and the longer it takes to deprecate it.

 

I submit that no year before 2016 is workable. You need to be fully aware of just how much C++ code exists out there. And just how much of it needs to compile and yet isn't being actively maintained.

Agreed. I am sorry if the life of library writers gets difficult by doing quick releases. But the more the community participates more people could join them.

 

And we're talking about a drop in replacement here, where any differences between `auto_ptr` and `unique_ptr` will be obvious, noisy, and quickly resolved. And some people still complain after six years of warning.

Sure, it stayed there for more than a decade.

Let's say we were to deprecate the string::operator string_view() in the next year. I am pretty sure that by 2019 it could be removed.

 

To remove a more widely used feature would require at least as much time if not more. So I fail to see how the 3 year period is a problem. You cannot practically remove features that people are using like that. Not if you want a language that works.

 

- Merging library TSs which do not require language changes

Then offload some of this work to the community.

You cannot publish an international standard based on random people on the Internet.

I'll appreciate if you'd read the whole thing before grumbling what can or cannot be done.

That has never been the idea.

 

One idea is having a centralized issue tracking where compiler and library maintainers and users could post defects or ask for improvements.

2) Stop using std::experimental and instead use std::alpha / std::beta (or anything that indicates how close such feature is to the final standard).

Companies/teams would be more comfortable adopting and testing pre-standard features.

Provide an easy to access matrix of these features but different of the current one currently on isocpp.org that only contains the proposal number and vendor/version availability it would also have:

- Synopsis of motivation

- A collection of practical examples

- A history of the decisions around the design

- Such matrix could be maintained by the community similarly as the Core Guidelines.

There's no way that's going to fit into a "matrix".

Have you ever heard about something called links to another page? Collapsing detailed views?

If you're trying to making difficult just for fun that's a terrible attitude.

 

Consider `std::variant`. That proposal went through a huge number of changes. And the proposals kept extensive notes documenting not only each change, but the committee votes responsible for it. The history section for some of those revisions required pages. You can't fit all of that into a "matrix".

3) Library proposals should have standard implementations which compile in all major compilers compliant with the targeted standard.

- I am aware this is close to a de facto requirement.

- But the change is that they would be centralized in a common repository.

- Library features could target an older standard if that makes sense.

- People not able or not willing to switch to a new standard could use the standard implementation.

- A standard implementation would stop to be maintained once part of the standard.

- If modified for adhering to a subsequent standard, it's assumed to be a new proposal.

4) All the ideas above use, if you will, the "github" model for driving the work around the standard.

But there's still room for a "StackOverflow" model to gauge interest and/or indicate deficiencies in the final product.

As soon as the model above is available the parts of the library/language with more questions are either:

- The "hot" features that everyone is looking into integrating in their work.

- Or, the ones lacking documentation or too difficult to be used by the average user of the language.

- StackOverflow itself can be used, no need to reinvent the will.

Those ideas aim to drive more people to participate in the new "maintenance" work group as well in providing feedback.

Again, what kind of "participation" are you talking about? Before you can start proposing solutions, you need to explain how, in your ideal world, people would be materially contributing to C++.

All kinds. It's an improvement over the status quo, it's a needed channel between community and standard.

I don't have all answers, I have an idea which believe is good and I am taking advantage of the existing channel to gauge interest and starting a discussion, which probably will continue in a different place.

 

 

They centralize the efford to make the standard happen - a single source of truth of sorts - that should be in the front page of isocpp.org.

I believe this also addresses the concerns of both the camp of "C++ evolution is sluguish" and the camp of "I can't keep up with C++".

Also, the experts are left alone to drive the evolution of the language every 3 years but they will be watched more closely by whole community involved in maintaining the current standard.

All this is suplemental to the current communities revolving around C++ such as clang, gcc, boost, etc. They would feed from the "standard" community and vice-versa.

That said, who's interested in convincing the committee and tackle this challenge? :)

Fork Clang and libc++, and go start your own language split from the needs of an ISO process. You can build whatever process you want for it.

Well, I wonder if what you just said wouldn't be reason enough to ban you from this mail list. It's a shame.

Actually, you may get what you're asking for. They were talking about that on Reddit yesterday...

[Ricardo Fabiano de Andrade]

On Fri, Sep 15, 2017 at 8:31 AM, Matthew Woehlke <mwoehlk...@gmail.com> wrote:

On 2017-09-14 23:43, Ricardo Fabiano de Andrade wrote:
> 1) Break the standard in two - language and library - but not literaly.
> Keep the 3-year cycle for language, have a much shorter (4-month /
> per-meeting?) cycle for library changes.

I just can't see this happening. Already, implementations lag behind the
standard, sometimes for years. Even at a three-year cycle, we're seeing
implementations struggling to have full support for the previous
standard before the next one is released.

Please note that I suggested that only library changes would be included in the shorter cycle.

Also, what you described is the past. Right now, we're very close to have the 3 major compiler vendors adhering fully to C++17.

Additions would be smaller and incremental!

 

There is also a VERY high bar for backwards compatibility. This is a
mixed blessing. On the one hand, it's important, because, unlike
stand-alone libraries, it is more difficult to use an older version of
the standard library. One can hope that their vendor develops the
standard library in a way that allows it to be used in compatibility
mode, but not all vendors do so (VS in particular comes to mind).

Take for example auto_ptr, which even though it's deprecated every standard library vendor has to provide an implementation.

The same would happen which all new library functionality moving forward, but in a much more granular and incremental way.

Yes, it could be a potential burden over library writers but I think the gains on participation and interest should overcome this challenge.

And about MSVC, they have even implemented standard compliance flags, so we have a common practice that would allow such change.

We need either the current, slow-to-change, long-term compatibility
model, or we need a better ecosystem of "common", granular, and
easy-to-obtain libraries more like the Python model. Both approaches
have disadvantages, which are often inherent to the problems they try to
solve.

I think that fast-change, medium-term compatibility is feasible without to radically change the standard.

It's a compromisse, you get a fast moving standard that may break a library feature every couple years and a language feature every 6.

Also, this is something I mentioned in a previous reply:

The longer something stays in the standard, the longer it must stay deprecated before being removed.

Moving faster provides an opportunity to pull failed ideas before they spread.

 

> 2) Stop using std::experimental and instead use std::alpha / std::beta (or
> anything that indicates how close such feature is to the final standard).
> Companies/teams would be more comfortable adopting and testing pre-standard
> features.

Do you have any evidence to support this?

Every single company I worked on since the days of C++0x refuse to use anything labeled std::experimental.

Yes, I could gather such evidence and put it in proposal if that's what you're asking.

But there's has been proposals (accepted?) for std2 and other namespaces for library evolution, so I think this is already an ongoing conversation within the committee.

 

In my experience, the reason developers are slow to adopt new features
is usually need to support older compilers. One project I work on has
only recently moved to full C++11... 5-6 years after that standard was
published. We've only been able to do so because a) we "finally" dropped
support for Red Hat 6, and b) VS2015 finally has decent support for that
standard.

Exactly, this is why my idea is about the future, not the past.

Since hopefully very soon we won't be plagued by absurd gaps among compiler vendors we can turn the dial and speed up things.

 

This situation may improve in the future, but if it does, it won't have
anything to do with naming conventions.

The whole idea is about communicating how close certain feature is to the final standard using the namespace.

std::experimental is a catch all net from draft proposal to pre-merge TS.

 

> 3) Library proposals should have standard implementations which compile in
> all major compilers compliant with the targeted standard.
> - I am aware this is close to a de facto requirement.
> - But the change is that they would be centralized in a common repository.

So, basically... you want to eliminate multiple standard library
implementations. There are advantages to that. There are also drawbacks.
You'd need an acceptable license. You'd need folks to agree to allow
compiler-specific code. You'd also need a solution for embedded
platforms, for which the full standard library is both unnecessary and
too big.

I imagined someone would understand that way, but I haven't said that.

Here's the catch: Those would be standard implementations of proposals. Once in the standard, that reference implementation would no longer be updated.

A library vendor could take that as-is and integrate in their standard library but that's unlikely to happen because every compiler has its own quirks and better ways of doing things.

The standard implementation of a proposal would aim to prove an idea, determine the behavior but probably wouldn't be the one with the best performance or compile time.

Which, don't get me wrong are important, but in the bar would be lower than in the vendor implementation.

 

On the other hand, if we went that route, we might as well all just use
something like Qt. Per above, by the time you solve *all* the problems
that moving in this direction entails, you've basically moved from the
current C++ standard library approach to something much more like Python.

I am sorry to hear that. It's the status quo speaking loudly.

At least this was just a little bit more polite than suggesting a fork...

Apparently not one is interested in solving these problems and that's very unfortunate.

 

--
Matthew

[Matthew Woehlke]

On 2017-09-15 11:06, Ricardo Fabiano de Andrade wrote:

> On Fri, Sep 15, 2017 at 8:31 AM, Matthew Woehlke wrote:
>> On the other hand, if we went that route, we might as well all just use
>> something like Qt. Per above, by the time you solve *all* the problems
>> that moving in this direction entails, you've basically moved from the
>> current C++ standard library approach to something much more like Python.
>
> I am sorry to hear that. It's the status quo speaking loudly.
> At least this was just a little bit more polite than suggesting a fork...
>
> Apparently not one is interested in solving these problems and that's very
> unfortunate.

The "impedance", if you will, between our views is that I am very much
unconvinced that having One True Monolithic Library that does everything
is actually a good thing. (You've heard the term "monopoly", I assume?
You're probably aware of its negative connotations?)

What I see as the problem isn't that "the C++ standard library can't do
X", it's that it's too hard to obtain an *existing* library that *does*
do "X".

*That* problem I am interested in solving. However, it's also somewhat
out of scope for "the C++ standard".

--
Matthew

[Paul "TBBle" Hampson]

On Friday, 15 September 2017 23:57:16 UTC+10, Richard Hodges wrote:

People who pay the wages of software engineers are more concerned with output per engineer. Adding another core to the cluster to make up for a minuscule loss of performance due to double-indirection of pointers or whatnot is way cheaper than paying someone to play around trying to get open source graphics libraries or crypto libraries to compile.

This might be specific to your application domain, where "Throw another core at it" is a feasible solution to "The program stopped for 50ms to run the garbage collector". And from a survey a few years back, (#5), it seems the people who pay the majority of C++ developer wages (by count *and* by value) are in areas where that's indeed not an option. And from my experience in such areas, boost is also not a common option, let alone a de-facto standard library.

 

The only way to increase the productivity of a c++ engineer to match that of a Java or Javascript dev is to give him comparably useful, standard, tools.

Why is that? Java and Javascript development *also* require going out and hunting down the appropriate libraries to get useful work done. Is it the existence of npm and Maven (is that right?) that makes the productivity difference?

Or does this relate to the previous idea, that for use-cases where Java or Javascript are better suited, it takes more work for C++ to be used as productively? That feels like a tautology to me.

[Paul "TBBle" Hampson]

On Saturday, 16 September 2017 02:24:08 UTC+10, Paul "TBBle" Hampson wrote:

On Friday, 15 September 2017 23:57:16 UTC+10, Richard Hodges wrote:

 

The only way to increase the productivity of a c++ engineer to match that of a Java or Javascript dev is to give him comparably useful, standard, tools.

Why is that? Java and Javascript development *also* require going out and hunting down the appropriate libraries to get useful work done. Is it the existence of npm and Maven (is that right?) that makes the productivity difference?

 

I might have over-trimmed. The context for this idea was an observation that in this discussion, Richard had commented on both the slowness of standardising C++ networking library, and also noted the use of boost::asio, a superset of what is likely to be the C++ networking library. That left me wondering if the concern was simply the namespace of the networking library code, and/or the ease-of-discovery of development libraries.

[Nicol Bolas]

On Friday, September 15, 2017 at 4:45:32 AM UTC-4, Bruce Adams wrote:

On Friday, 15 September 2017 06:10:45 UTC+1, Nicol Bolas wrote:

On Thursday, September 14, 2017 at 11:43:51 PM UTC-4, Ricardo Andrade wrote:

Even though I totally disagree with Richard's tone in this discussion I do understand his frustration with the current status quo of C++. I felt like this myself in several occasions.

Despite my admiration for the members of the committee and all the effort they put in the standard, I think there's plenty of room for improvement in a few areas.

The most critical in my opinion is that the communication channel between community and committee is too narrow and therefore the feedback is insufficient.

There's no clear path for trying a new library or language features.

As example, it doesn't matter if string_view has been available for several years if no one knows about it, which purpose is it supposed to serve and how to use it.

It's very hard for someone that doesn't follow the standard to get to know about a proposal and where to try it.

"Where to try it" is not something the standards committee can deal with. The committee publishes standards, not implementations.

True but many developments demand implementation experience. The conscientious proposers put their implementations on an open source repository somewhere

and reference it in the proposal. There is an argument that they could belong together in the same incubator.

I don't really see the point in that. If every library proposal has a link to an implementation, it doesn't really matter if they're all in the same repo/whatever or not. What matters is that you can go from proposal to an implementation.

One idea is having a centralized issue tracking where compiler and library maintainers and users could post defects or ask for improvements.

2) Stop using std::experimental and instead use std::alpha / std::beta (or anything that indicates how close such feature is to the final standard).

Companies/teams would be more comfortable adopting and testing pre-standard features.

Provide an easy to access matrix of these features but different of the current one currently on isocpp.org that only contains the proposal number and vendor/version availability it would also have:

- Synopsis of motivation

- A collection of practical examples

- A history of the decisions around the design

- Such matrix could be maintained by the community similarly as the Core Guidelines.

There's no way that's going to fit into a "matrix".

Consider `std::variant`. That proposal went through a huge number of changes. And the proposals kept extensive notes documenting not only each change, but the committee votes responsible for it. The history section for some of those revisions required pages. You can't fit all of that into a "matrix".

This to my mind is where issue trackers and wiki's fit in.

You mean like this one ;)

Now, it is almost criminal that this site is not better publicized. And it's really annoying that proposal numbers aren't directly related to the bugs in those lists. And it's unfortunate that it uses Bugzilla's crappy system. But it's still a great resource for following library proposals.

[Matthew Woehlke]

On 2017-09-15 12:24, Paul "TBBle" Hampson wrote:
> On Friday, 15 September 2017 23:57:16 UTC+10, Richard Hodges wrote:
>> The only way to increase the productivity of a c++ engineer to match that
>> of a Java or Javascript dev is to give him comparably useful, standard,
>> tools.
>
> Why is that? Java and Javascript development *also* require going out and
> hunting down the appropriate libraries to get useful work done. Is it the
> existence of npm and Maven (is that right?) that makes the productivity
> difference?

IMHO? Yes. That, and a common virtual machine for code execution, which
makes it much, much easier to distribute "ready to run" artifacts.

Or, take Python as another example (mostly because I am more familiar
with Python than Java[script]). Most times, using a library is as easy as:

$ pip install some_lib

# my.py
import some_lib

Compare that to C++. I have to download the library source and hope that
it compiles without errors on my machine, or else hope there is a
pre-built binary that is compatible with my OS and compiler. Before I
can do even that, I have to do the same for the library's dependencies,
and their dependencies, and so on. Even after that, I have to figure out
what I need to do in my project to *use* that library, which itself is
much more complicated than in Python/Java/etc.

I don't see that "obtain the library" can be fixed besides having a good
package manager, which is mainly a problem on Windows (and to a lesser
extent, macOS).

How to *use* a package once it's been obtained is more tractable, though
not really in the scope of "the C++ standard". pkg-config tried to solve
this problem, but has a number of issues. CPS¹ seems plausible, but
needs folks to do the work to implement, use, and promote it.

¹ https://mwoehlke.github.io/cps/

--
Matthew

[Richard Hodges]

> Why is that? Java and Javascript development *also* require going out and hunting down the appropriate libraries to get useful work done. Is it the  existence of npm and Maven (is that right?) that makes the productivity difference?

This is a very fair point. A standard c++ package manager that understood cross-compiling and the (automatic?) selection of static or dynamic libraries would be an enormous productivity boost.

That alone would make my productivity in c++ at least as good as it is in javascript.

> This might be specific to your application domain, ...

> Or does this relate to the previous idea, that for use-cases where Java or Javascript are better suited, it takes more work for C++ to be used as productively? That feels like a tautology to me.

My personal view is that I would rather write code once. 

My problem domain covers servers, server tools, clients and web clients.

I use c++ (for historical and preference reasons) and share libraries across all these domains.

One of the reasons I like c++ is that the type system is so powerful that I can almost prove program correctness simply because the program compiles.

 

Astonishingly we're also able to do this in the browsers, courtesy of the *stunning* emscripten tool - which uses clang to transpile c++14 into bytecode executed in javascript in a browser.

c++ is a truly a universal tool, and much loved. It's let down by the lack of standardised build and package management support, without doubt.

The only time I waste, in comparison to writing in javascript, python, bash script, et al is fiddling about with the damn build scripts.

Other than the time spent ranting here, obviously :)

> 

--

[Nicol Bolas]

On Friday, September 15, 2017 at 10:35:00 AM UTC-4, Ricardo Andrade wrote:

On Fri, Sep 15, 2017 at 12:10 AM, Nicol Bolas <jmck...@gmail.com> wrote:

On Thursday, September 14, 2017 at 11:43:51 PM UTC-4, Ricardo Andrade wrote:

Even though I totally disagree with Richard's tone in this discussion I do understand his frustration with the current status quo of C++. I felt like this myself in several occasions.

Despite my admiration for the members of the committee and all the effort they put in the standard, I think there's plenty of room for improvement in a few areas.

The most critical in my opinion is that the communication channel between community and committee is too narrow and therefore the feedback is insufficient.

There's no clear path for trying a new library or language features.

As example, it doesn't matter if string_view has been available for several years if no one knows about it, which purpose is it supposed to serve and how to use it.

It's very hard for someone that doesn't follow the standard to get to know about a proposal and where to try it.

"Where to try it" is not something the standards committee can deal with. The committee publishes standards, not implementations.

Which is very narrow way of thinking. You put a lot of effort on something for a target audience but they are never going to try it. Or worst, when they try, they hate it.

That's why I am suggesting ways of bringing the community to more actively participate, to bridge this gap.

So... where does this "gap" come from? What evidence is there that this gap exists?

Because as far as I can tell, library proposals do get scrutinized and adjusted based on user feedback. I don't see a whole lot of stuff going into the standard that the community as a whole feels is broken. Oh sure, some people will disagree with some things, but that's going to happen no matter what you pick.

The community's main problem with the standard (or rather, some people in the community) is that it's not adding enough stuff fast enough. And that won't change just because you create a direct complaint channel to committee members.

The Networking TS was not put into the standard due to a lack of user-feedback. It wasn't still being worked on due to not having enough people workshopping it. That's just how long it takes, even when starting from a solid library, to develop a standard feature of such complexity. Adding more people giving "feedback" would not speed that process up.

This "gap" you talk about also assumes that the committee is not actually part of the user base of the stuff they create.

As for knowing about a proposal... I really don't know how much more the committee can do. There's an entire website whose sole purpose is to be where standard C++ news items happen. That website publishes the mailings, which contain all of the proposals in question.

What more do you want?

Knowing where to find the implementations of a proposal so I can try, know about the design decisions around a proposal so I can decide for myself if in favor or against it... and more importantly IN A SINGLE PLACE.

Saying that std proposals mail list is this place is a extremely short sighted view of what could be done.

... I never suggested it was. The site I was referring to is `isocpp.org`.

The committee is counting on volunteers but there's no effort to make this need explicit. Honestly, a language complex as C++ needs all the help one can get.

And a language as complex as C++ needs as little of the wrong kind of help as it can get. That's really important too.

First, there's no wrong kind of help.

Well, that explains everything. If you start from the presumption that all commentary is created equal, then I can see where you're coming from.

Sadly, there is no evidence for the accuracy of such a point of view. There is plenty of "help" that is wrong, which leads you decidedly away from accomplishing things.

 

There's a misguided effort. Again, communication is important to avoid that.

Second, I am not proposing a direct democracy kind of participation.

My idea is:

- The community drives the new work group working on minor versions standards.

- The new work group acts as a filter and as a guide for the community.

- The feedback is taken to other work groups working on the major version of the standard.

Finally, is committee open or not? You are contradicting your own arguments.

It is open. But you have to actually participate. You can't just walk by on your free time and drop off an idea, with the assumption that someone else will make it real.

 

On the contrary, the few channels available (this one and std proposals) are very closed (and sometimes it feels unwelcoming) to the general community.

I'm not sure how much more open you can get by having a forum/mailing list that literally anybody can sign up to use. The forums may be well-hidden, but once you find them, they're right here.

I am sure it can get more open and that's my proposal.

"The forums may be well-hidden" = wrong!

What are you hiding from? Uncomfortable questions? Challenged assumptions?

Yes, I intend to pop your bubble!

... I wasn't saying that these forums not being easy to find was a good thing. I was merely stating a fact, that they're not well-publicized.

 

The community gets their hands on language and library changes very late in the process.

And boost can't serve much as a test bed because the experience has been proving that once something from boost passes through the committee, a whole lot changes.

Most of the record of such changes and decisions is closed to the general community - because ISO doesn't allow that to be public in some cases.

The majority of the community is not interested in submitting proposals. The bar is too high and it's too big of a commitment.

But everyone is eager to try the "next big thing". The current process is missing all this participation.

I'm not sure how useful such participation would be. If you're not able to put together a proposal... what exactly can you do to improve the standard? Ideas are easy; it's the details that are hard. And it's the details that we need.

My testing the proposals in the real world. Isn't that the idea behind a TS anyway?

TS's have details.

Again, if you want some kind of collective proposal development system, that's fine. But it still needs to lead to an actual proposal, not a bunch of ideas or functions that someone else has to cobble together into a working whole.

Agreed. I am not proposing a change in the process. Just more ways to drive the process and provide feedback.

 

So what would this participation be, providing commentary on proposals? That just requires people who have actual domain knowledge to spend their time sifting through the 90% of worthless comments for the occasional nugget of genuinely useful information. That is a huge waste of time.

You just said that the C++ community is incapable of using the resulting work of the committee.

That by itself is problem.

Again, there must be a filter - a moderator - capable of both understand the community feedback and take it to the committee.

And who will that be? Who's going to want to waste their time on the tons and tons of garbage feedback, just to dig out a few crumbs of useful stuff?

If you want to take community driven proposals to the committee, you have the right to do that right now. But that's not something that the committee is going to enforce or should build specific channels to accomplish.

The kind of feedback you're talking about is useful only to the extent that the committee is not getting enough feedback within itself and its existing apparatus. Do you have any evidence that proposals are being passed without sufficient feedback? That concerns about proposals have gone unaddressed or undiscussed by the committee?

OK, let's wind the clocks back to 2011. C++11 is about to be published, and you're going to deprecate `auto_ptr`. And this time, you're deprecating it with the expressed idea of replacing it with `unique_ptr`. So you're serious about it.

I can't do anything about the past but let's go with your arguments...

 

Now, forget everything about how long it takes to publish another standard. If you had to pick a year, what year would you say "OK, everyone's had enough time to switch to `unique_ptr`, so we're eliminating `auto_ptr`"?

The more you put in the standard the longer it takes... the longer something stays in the standard, the more it gets used and the longer it takes to deprecate it.

 

I submit that no year before 2016 is workable. You need to be fully aware of just how much C++ code exists out there. And just how much of it needs to compile and yet isn't being actively maintained.

Agreed. I am sorry if the life of library writers gets difficult by doing quick releases. But the more the community participates more people could join them.

 

And we're talking about a drop in replacement here, where any differences between `auto_ptr` and `unique_ptr` will be obvious, noisy, and quickly resolved. And some people still complain after six years of warning.

Sure, it stayed there for more than a decade.

Let's say we were to deprecate the string::operator string_view() in the next year. I am pretty sure that by 2019 it could be removed.

... I don't understand what you're saying.

You agreed with me that `auto_ptr` taking 5+ years to be removed is a good and reasonable thing. That the time period wasn't driven by a slow release schedule but by a reasonable period of getting programmers to stop using a tool.

So why would you say that the implicit conversion of string view could be removed in one year's time?

[Nicol Bolas]

I think we can get pretty much universal agreement that C++ package management sucks and is a drag on C++ development. But that's not something the ISO Standard can mandate. It's not that we don't need it; it's that it is unreasonable to expect the C++ standards committee to be able to do anything about it.

--
Matthew

[Richard Hodges]

> it's that it is unreasonable to expect the C++ standards committee to be able to do anything about it.

[Richard Hodges]

(forgive the double post)

> it's that it is unreasonable to expect the C++ standards committee to be able to do anything about it.

If it's the single biggest impediment to c++ adoption, usefulness and productivity then I think there's a very real argument that the committee should focus on nothing else until it's solved.

After all, with java you can jump dump a zip file in a classpath and bob's your uncle.

Why not with c++?

 

[Michael Kilburn]

On Thursday, September 14, 2017 at 10:43:51 PM UTC-5, Ricardo Andrade wrote:

1) Break the standard in two - language and library - but not literaly.

I think it is a brilliant idea. Afaik, most of the STL can be implemented in pure C++ without need for vendor-specific magic. Leave those bits (that have to be implemented by vendor) in C++ standard and move the rest into "STL standard" (and even split it further). This would allow for better implementations to squeeze out bad ones -- I will be able to simply pick one I prefer (or that has better performance characteristics for my type of tasks) and use it in my project. 

I am so tired of discovering that my implementation copies data from streambuf byte-by-byte and I can't really do anything about because it is in "vendor" land.

 

Keep the 3-year cycle for language, have a much shorter (4-month / per-meeting?) cycle for library changes.

Organize a different work group for the short cycle to not drawn resources away from the main work groups.

What could be done under these short cycles:

- Fixing defect reports

- Improve on usabiliy and ease-of-use issues (example: make_unique)

- Test library-only solutions that may demand languange additions not certain to be worth

- Deprecating library features

- Remove deprecated library features

- Merging library TSs which do not require language changes

Then offload some of this work to the community.

One idea is having a centralized issue tracking where compiler and library maintainers and users could post defects or ask for improvements.

Yes, and you'll be able to have multiple competing library implementations. While right now you get stuck with whatever vendor gave you (and vendor hurts too -- he can't concentrate only on compiler, has to implement STL too -- which gets harder and harder over time).

:-)

 

[Matthew Woehlke]

Well... yes. When I said *consuming* packages was "not really in the
scope of 'the C++ standard'", that wasn't meant to imply that
*obtaining* packages *is* in scope. Obtaining packages is even less in
scope than consuming packages.

(I could conceive, without saying I think it's a good idea, that C++
headers would have some mechanism of informing the linker that a library
needs to be linked. That sort of thing *might* be in scope, although
even that might be a stretch. Plus I'm dubious that that would be the
best approach.)

On 2017-09-15 13:21, Richard Hodges wrote:
> After all, with java you can jump dump a zip file in a classpath and bob's
> your uncle.
>
> Why not with c++?

In short, because Java doesn't have to deal with the sorts of platform
inconsistencies that C++ does.

Now, I do agree that it would be great if things *could* be made that
easy. (*Actually* just dropping in an existing artifact is almost
certainly impossible, but being as easy as asking the package manager -
which *already exists on the system* - to install the package seems
plausible, and a worthwhile goal.)

Per above, though, you're going to have a very hard time convincing WG21
that they are the correct group to solve these sorts of problems.

(I honestly can't say why there doesn't seem to be more activity in this
area. It does seem that "everyone" knows about the problem, but no one
has stepped forward to do something about it. Although, it would help to
have buy-in from Microsoft, since they're the platform with the biggest
lack...)

--
Matthew

[Ricardo Fabiano de Andrade]

On Fri, Sep 15, 2017 at 11:10 AM, Matthew Woehlke <mwoehlk...@gmail.com> wrote:

On 2017-09-15 11:06, Ricardo Fabiano de Andrade wrote:
> On Fri, Sep 15, 2017 at 8:31 AM, Matthew Woehlke wrote:
>> On the other hand, if we went that route, we might as well all just use
>> something like Qt. Per above, by the time you solve *all* the problems
>> that moving in this direction entails, you've basically moved from the
>> current C++ standard library approach to something much more like Python.
>
> I am sorry to hear that. It's the status quo speaking loudly.
> At least this was just a little bit more polite than suggesting a fork...
>
> Apparently not one is interested in solving these problems and that's very
> unfortunate.

The "impedance", if you will, between our views is that I am very much
unconvinced that having One True Monolithic Library that does everything
is actually a good thing. (You've heard the term "monopoly", I assume?
You're probably aware of its negative connotations?)

Ah I see where you coming from now.

You're attaining to the point of a growing standard library...

That has never been my main goal, even though that could happen over time.

But since that's not the current problem, let's no worry about it at this time.

Honestly, I couldn't care less for networking TS for example. I am good with ASIO.

There are some pros in having that in the standard but major cons.

When I mentioned a TS before, I had ranges in mind.

All I wanted is that the fundamental parts of the standard library (containers, algorithms, string, variant, tuple, smart pointers, etc.) could be accessible for user of varying expertise levels.

And that some warts could be slowly replaced with better, less error-prone solutions.

Of course, the community could ask for something like JSON support, for example.

But with the right guidance, one could argue that having serialization support would be more beneficial for the whole community and that should be tackled instead.

 

What I see as the problem isn't that "the C++ standard library can't do
X", it's that it's too hard to obtain an *existing* library that *does*
do "X".

*That* problem I am interested in solving. However, it's also somewhat
out of scope for "the C++ standard".

It depends. If it's something fundamental to support the language, I don't see why not.

[Matthew Woehlke]

On 2017-09-15 13:56, Michael Kilburn wrote:
> [...] and you'll be able to have multiple competing library implementations.

...which sort of defeats the purpose of *standardization*.

What happens when you want to use Library A, which was built against Foo
STL, with Library B, which was built against Bar STL.

We already have problems in the wild with e.g. trying to build an
application that uses one library that ultimately uses, say, Qt4, and
also uses another library that ultimately uses Qt5. This doesn't end
well. Do you really want to propose that we can create that sort of mess
with *the standard library*?

...or did you miss out on all the libc++ vs. libstdc++ excitement?
(Yeah. We've already been-there, done-that...)

Besides, in order for that to work out *at all*, we still need to solve
the distribution and consumption problems.

We might as well start with those first...

--
Matthew