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

[o***@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 <https://github.com/facebook/osquery> we use Thrift to
communicate with extensions.
Thrift has hardcoded
<https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/generate/t_cpp_generator.cc#L4242>
the string type it generates for C++. Even if we did use
std::variant<std::string, std::string_view> for RowData
<https://github.com/facebook/osquery/blob/master/include/osquery/query.h#L29>
we'd still have to copy some of the string_views from Row
<https://github.com/facebook/osquery/blob/master/include/osquery/query.h#L37>
into ExtensionPluginResponse
<https://github.com/facebook/osquery/blob/master/osquery.thrift#L5> 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, <***@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.

[Ross Smith]

Post by o***@gmail.com
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]

Post by Ross Smith

Post by o***@gmail.com
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).

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

[Patrice Roy]

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

Post by Ville Voutilainen

Post by Ross Smith

Post by o***@gmail.com
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).

Correct, but a string_view is not necessarily nul-terminated.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Thiago Macieira]

Post by Patrice Roy
@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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Patrice Roy]

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

Post by Thiago Macieira

Post by Patrice Roy
@Ville : would that be a problem in this case, since the source is known

to

Post by Patrice Roy
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Paul "TBBle" Hampson]

Post by Thiago Macieira

Post by Patrice Roy
@Ville : would that be a problem in this case, since the source is known

to

Post by Patrice Roy
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]

Post by Paul "TBBle" Hampson
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[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.

Post by Thiago Macieira

Post by Paul "TBBle" Hampson
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by Richard Hodges
IMHO the only 'safe' interface for the constructor of a string_view is one
(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?
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]

Post by Nicol Bolas
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?

Post by Nicol Bolas
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.

Post by Nicol Bolas

Post by Richard Hodges
IMHO the only 'safe' interface for the constructor of a string_view is
(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?
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by Nicol Bolas

Post by Nicol Bolas
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?

Post by Nicol Bolas
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.

[Richard Hodges]

Post by Nicol Bolas
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.

Post by Nicol Bolas

Post by Nicol Bolas
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?

Post by Nicol Bolas
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by Nicol Bolas

Post by Nicol Bolas
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.
template<class SomeStoragePolicy> struct immutable_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. :)

Post by Nicol Bolas
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.
template<class SomeStoragePolicy> struct immutable_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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Ville Voutilainen]

Post by Richard Hodges

We should not...

citation needed. :)

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

Post by Richard Hodges

Post by Richard Hodges

Post by Nicol Bolas
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.
template<class SomeStoragePolicy> struct immutable_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.

[Nevin Liber]

Post by Richard Hodges

Post by Richard Hodges
IMHO the only 'safe' interface for the constructor of a string_view is
(const char* first, const char* last), or

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

Doesn't seem safe to me.

Post by Richard Hodges
(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.

Post by Richard Hodges
(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.
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]
<(847)%20691-1404>

[Richard Hodges]

Post by Nevin Liber
string_view sv0(GetCString(), GetAnotherCString());

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

Post by Nevin Liber
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.

Post by Nevin Liber
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.

Post by Nevin Liber
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.

Post by Nevin Liber
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).

Post by Nevin Liber
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.

Post by Nevin Liber

Post by Richard Hodges

Post by Richard Hodges
IMHO the only 'safe' interface for the constructor of a string_view is
(const char* first, const char* last), or

string_view sv0(GetCString(), GetAnotherCString());
Doesn't seem safe to me.

Post by Richard Hodges
(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.

Post by Richard Hodges
(Iter first, Iter last)

list<char> lc = Bar();
string_view sv2(lc.begin(), lc.end());
Doesn't seem safe to me.
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.
--
<(847)%20691-1404>
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Richard Hodges]

Post by Richard Hodges
and accept const char&

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

Post by Richard Hodges

Post by Nevin Liber
string_view sv0(GetCString(), GetAnotherCString());

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

Post by Nevin Liber
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.

Post by Nevin Liber
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.

Post by Nevin Liber
return string_view(vc);

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.

Post by Nevin Liber
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).

Post by Nevin Liber
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.

Post by Nevin Liber

Post by Richard Hodges

Post by Richard Hodges
IMHO the only 'safe' interface for the constructor of a string_view is
(const char* first, const char* last), or

string_view sv0(GetCString(), GetAnotherCString());
Doesn't seem safe to me.

Post by Richard Hodges
(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.

Post by Richard Hodges
(Iter first, Iter last)

list<char> lc = Bar();
string_view sv2(lc.begin(), lc.end());
Doesn't seem safe to me.
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.
--
<(847)%20691-1404>
--
---
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
Visit this group at https://groups.google.com/a/is
ocpp.org/group/std-discussion/.

[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]

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.

Post by Nicol Bolas
The question ultimately comes down to two pieces of code.
void some_func(string_view s);
some_func("a string"s);
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Matthew Woehlke]

Post by Richard Hodges
There is another very pertinent case that you've missed, I'll get to that
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.

Post by Richard Hodges
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]

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]

Post by Howard Hinnant
This is a great example, and I think the beginning of a good guideline.

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

Post by Howard Hinnant

Post by Richard Hodges
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".

Post by Richard Hodges
And the CurrencyPair class gets refactored to : auto

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

Post by Richard Hodges
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.
auto
CurrencyPair::base() &
-> std::string_view
{
return std::string_view(ccypair_).substr(0, 3);
};
auto
CurrencyPair::base() &&
-> std::string
{
return ccypair_.substr(0, 3);
};
Howard
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nevin Liber]

Post by Richard Hodges

Post by Howard Hinnant
This is a great example, and I think the beginning of a good guideline.

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.
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.
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[Richard Hodges]

Post by 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.

Post by Richard Hodges

Post by Richard Hodges

Post by Howard Hinnant
This is a great example, and I think the beginning of a good guideline.

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.
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.
--
<+1%20847-691-1404>
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Howard Hinnant]

Post by Howard Hinnant
This is a great example, and I think the beginning of a good guideline.

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.
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]

Post by Howard Hinnant
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

Post by Howard Hinnant

Post by Nevin Liber

Post by Richard Hodges

Post by Howard Hinnant
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

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.

Post by Nevin Liber

Post by Richard Hodges
In which case the refactorer now has to supply 2 almost-identical
struct CurrencyPair
{
auto base() const& -> std::string_view; // sort of safe, provided

the caller does not assign to an auto unwittingly

Post by Nevin Liber

Post by Richard Hodges
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.

Post by Nevin Liber
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
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nevin Liber]

Post by Howard Hinnant
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.
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]
<(847)%20691-1404>

[Howard Hinnant]

Post by Howard Hinnant
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.
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.

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]

Post by Howard Hinnant
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

Post by Howard Hinnant

On Wed, Sep 6, 2017 at 11:50 AM, Howard Hinnant <
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.

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.
That’s a great example Nevin, thanks for the code.
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
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Ross Smith]

Post by Richard Hodges
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]

Post by Ross Smith
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.

Post by Ross Smith

Post by Richard Hodges
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.

Post by Richard Hodges
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
--
---
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
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Nicol Bolas]

Post by Ross Smith

Post by Ross Smith
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

Post by Ross Smith
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?

Post by Ross Smith
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

Post by Ross Smith
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

Post by Ross Smith
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

Post by Ross Smith
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.

And I can't afford a segfault on a production server.

Post by Ross Smith

Post by Ross Smith

Post by Richard Hodges
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.

Post by Richard Hodges
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
--
---
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
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Richard Hodges]

Post by Nicol Bolas
But that doesn't make it *wrong*.

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

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas

Post by Ross Smith

Post by Ross Smith
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

Post by Ross Smith
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?

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

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

Post by Ross Smith
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

Post by Ross Smith
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

Post by Ross Smith
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.
And I can't afford a segfault on a production server.

Post by Ross Smith

Post by Ross Smith

Post by Richard Hodges
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"

Post by Richard Hodges
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.

Post by Richard Hodges
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
--
---
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
Visit this group at https://groups.google.com/a/is
ocpp.org/group/std-discussion/.

--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

['Bruce Adams' via ISO C++ Standard - Discussion]

Post by Richard Hodges

Post by Nicol Bolas
But that doesn't make it *wrong*.

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

Post by Nicol Bolas
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.

Post by Nicol Bolas
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

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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***@wargaming.net]

Post by Nicol Bolas

Post by Richard Hodges
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.

Post by Nicol Bolas
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]

Post by 'Bruce Adams' via ISO C++ Standard - Discussion

Post by Richard Hodges

Post by Nicol Bolas
But that doesn't make it *wrong*.

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

Post by Nicol Bolas
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.

Post by Nicol Bolas
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

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

Post by 'Bruce Adams' via ISO C++ Standard - Discussion
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

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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
<https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals>. 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]

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas

Post by Richard Hodges

Post by Nicol Bolas
But that doesn't make it *wrong*.

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

Post by Nicol Bolas
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.

Post by Nicol Bolas
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

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

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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
<https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals>. 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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Thiago Macieira]

Post by Richard Hodges

Post by Nicol Bolas
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.

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

No, it's not.

Post by Richard Hodges
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.

Post by Richard Hodges
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.

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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.

Post by Richard Hodges
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?

Post by Richard Hodges
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.

Post by Richard Hodges
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.

Post by Richard Hodges
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]

Post by Thiago Macieira
We're humans, we make mistakes. We just have to *learn* from those

mistakes., and

Post by Thiago Macieira
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

Post by Thiago Macieira
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.

Post by Thiago Macieira

Post by Richard Hodges
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.

Post by Thiago Macieira
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.

Post by Thiago Macieira
The C++ committee works around the ISO limitations and requirements just

fine.

Post by Thiago Macieira
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.

Post by Thiago Macieira
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.

Post by Thiago Macieira

Post by Richard Hodges

Post by Nicol Bolas
What he's looking for, I suspect, is a direct conduit to the

committee. A

Post by Richard Hodges

Post by Nicol Bolas
place where he can lay out his arguments and the committee members

would
be

Post by Richard Hodges

Post by Nicol Bolas
*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.

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

No, it's not.

Post by Richard Hodges
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.

Post by Richard Hodges
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.

Post by Richard Hodges

Post by Nicol Bolas
Standards need to be things that can stand the test of time.

DirectX, for all its sins, lasted 20 years, each evolution compatible

with

Post by Richard Hodges
the previous. Games that were written with it 20 years ago still run

(under

Post by Richard Hodges
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.

Post by Richard Hodges
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'

Post by Richard Hodges
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.

Post by Richard Hodges
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

Post by Richard Hodges
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?

Post by Richard Hodges
The c++ standard should also evolve. No committee will get everything

right

Post by Richard Hodges
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

Post by Richard Hodges
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.

Post by Richard Hodges
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

Post by Richard Hodges
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.

Post by Richard Hodges
The application interfaces should be similar. Libraries that provided the
standard interface (i.e. passed the set of standard unit tests) could be

so

Post by Richard Hodges
marked *and certificated*. This would give vendors encouragement and
incentive to make them so, even if they provide their own custom

interfaces

Post by Richard Hodges
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
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Hyman Rosen]

Post by Richard Hodges
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.

[FrankHB1989]

圚 2017幎9月14日星期四 UTC+8䞊午12:57:00Hyman Rosen写道

Post by Hyman Rosen

Post by Richard Hodges
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.
<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.*
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.

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.

[Hyman Rosen]

Post by FrankHB1989
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.

[Ville Voutilainen]

Post by Hyman Rosen
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.

[FrankHB1989]

圚 2017幎9月15日星期五 UTC+8䞊午12:37:55Hyman Rosen写道

Post by Hyman Rosen

Post by FrankHB1989
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,

Post by Hyman Rosen
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.

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 *n*th 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 Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges

Post by Thiago Macieira
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.

Post by Thiago Macieira

Post by Richard Hodges
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.

Post by Thiago Macieira
The C++ committee works around the ISO limitations and requirements

just fine.

Post by Thiago Macieira
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]

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas
On Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges

Post by Thiago Macieira
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.

Post by Thiago Macieira

Post by Richard Hodges
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.

Post by Thiago Macieira
The C++ committee works around the ISO limitations and requirements

just fine.

Post by Thiago Macieira
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Thiago Macieira]

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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?

Post by Richard Hodges
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.

Post by Richard Hodges
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.

Post by Richard Hodges
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Nicol Bolas]

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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

Post by Richard Hodges
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.

[Richard Hodges]

Post by Nicol Bolas
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.

Post by Nicol Bolas

Post by Richard Hodges

Post by Nicol Bolas
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.

Post by Richard Hodges
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

Post by Richard Hodges
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[b***@gmail.com]

Post by Nicol Bolas
Many of the libraries you're talking about are big; much larger than

most SO questions or answers.... etc
This is reducto ad absurdum.
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]

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.

Post by b***@gmail.com

Post by Nicol Bolas
Many of the libraries you're talking about are big; much larger than

most SO questions or answers.... etc
This is reducto ad absurdum.
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Ville Voutilainen]

Post by Richard Hodges

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]

Post by Richard Hodges
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

Post by Richard Hodges
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

Post by Richard Hodges
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

Post by Richard Hodges
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]

Post by Nicol Bolas
Many of the libraries you're talking about are big; much larger than

most SO questions or answers.... etc
This is reducto ad absurdum.
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?

Post by Nicol Bolas

Post by Nicol Bolas
Many of the libraries you're talking about are big; much larger than

most SO questions or answers.... etc
This is reducto ad absurdum.
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by Richard Hodges
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.

Post by Richard Hodges
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]

Post by Nicol Bolas
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]

Post by Nicol Bolas
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.



On 14 September 2017 at 21:48, Ville Voutilainen <

Post by Nicol Bolas

Post by Nicol Bolas
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

Post by Nicol Bolas
doing that, then people wouldn't be disappointed when they don't pan out.

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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[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? :)

Post by Richard Hodges

Post by Nicol Bolas
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

Post by Nicol Bolas
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.
On 14 September 2017 at 21:48, Ville Voutilainen <

Post by Nicol Bolas

Post by Nicol Bolas
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

Post by Nicol Bolas
doing that, then people wouldn't be disappointed when they don't pan

out.
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.
--
---
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
Visit this group at https://groups.google.com/a/is
ocpp.org/group/std-discussion/.

--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by 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.

"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

Post by Ricardo Fabiano de Andrade
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)

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
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.
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

Post by Ricardo Fabiano de Andrade
away from the main work groups.
- 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.

Post by Ricardo Fabiano de Andrade
- 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

Post by Ricardo Fabiano de Andrade
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
- 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

Post by Ricardo Fabiano de Andrade
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
- 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++.

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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]

Post by Nicol Bolas
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.

Post by Nicol Bolas

Post by 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.

"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

Post by Ricardo Fabiano de Andrade
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)

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
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.
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

Post by Ricardo Fabiano de Andrade
away from the main work groups.
- 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.

Post by Ricardo Fabiano de Andrade
- 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

Post by Ricardo Fabiano de Andrade
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
- 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

Post by Ricardo Fabiano de Andrade
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
- 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++.

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

['Bruce Adams' via ISO C++ Standard - Discussion]

Post by Richard Hodges

Post by Nicol Bolas
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.

['Bruce Adams' via ISO C++ Standard - Discussion]

Post by Nicol Bolas

Post by 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.

"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

Post by Nicol Bolas
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

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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)

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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".

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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?

Post by Nicol Bolas
One idea is having a centralized issue tracking where compiler and library

Post by Ricardo Fabiano de Andrade
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
- 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.

Post by Nicol Bolas
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++.

[Nicol Bolas]

Post by 'Bruce Adams' via ISO C++ Standard - Discussion

Post by Nicol Bolas

Post by 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.

"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

Post by 'Bruce Adams' via ISO C++ Standard - Discussion

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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
- 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
<https://issues.isocpp.org/buglist.cgi?component=Library&product=C%2B%2B&resolution=--->
;)

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.

[Ricardo Fabiano de Andrade]

Post by Nicol Bolas

Post by 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.

"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.

Post by Nicol Bolas
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...

Post by Nicol Bolas
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.

Post by Nicol Bolas
The committee is counting on volunteers but there's no effort to make this

Post by Ricardo Fabiano de Andrade
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.

Post by Nicol Bolas
On the contrary, the few channels available (this one and std proposals)

Post by Ricardo Fabiano de Andrade
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!

Post by Nicol Bolas
The community gets their hands on language and library changes very late

Post by Ricardo Fabiano de Andrade
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?

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas
Change is slow and corrections even slower.

Post by Ricardo Fabiano de Andrade
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.
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.

Post by Nicol Bolas
Organize a different work group for the short cycle to not drawn resources

Post by Ricardo Fabiano de Andrade
away from the main work groups.
- 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...

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Ricardo Fabiano de Andrade
- 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.

Post by Nicol Bolas
One idea is having a centralized issue tracking where compiler and library

Post by Ricardo Fabiano de Andrade
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
- 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.

Post by Nicol Bolas
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

Post by Ricardo Fabiano de Andrade
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
- 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.

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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...
--

Post by Nicol Bolas
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by Ricardo Fabiano de Andrade

Post by Nicol Bolas

Post by 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.

"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

Post by Ricardo Fabiano de Andrade

Post by Nicol Bolas
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

Post by Ricardo Fabiano de Andrade

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
There's a misguided effort. Again, communication is important to avoid
that.
Second, I am not proposing a direct democracy kind of participation.
- 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.

Post by Ricardo Fabiano de Andrade

Post by Nicol Bolas
On the contrary, the few channels available (this one and std proposals)

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
The community gets their hands on language and library changes very late

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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,

Post by Ricardo Fabiano de Andrade

Post by Nicol Bolas
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.

Post by Nicol Bolas
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

Post by Ricardo Fabiano de Andrade

Post by Nicol Bolas

Post by Ricardo Fabiano de Andrade
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...

Post by Nicol Bolas
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.

Post by Nicol Bolas
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.

Post by Nicol Bolas
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?

[Matthew Woehlke]

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
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]

Post by Matthew Woehlke
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

Post by Matthew Woehlke

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
2) Stop using std::experimental and instead use std::alpha / std::beta

(or

Post by Ricardo Fabiano de Andrade
anything that indicates how close such feature is to the final standard).
Companies/teams would be more comfortable adopting and testing

pre-standard

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
3) Library proposals should have standard implementations which compile

in

Post by Ricardo Fabiano de Andrade
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
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Paul "TBBle" Hampson]

Post by Richard Hodges
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
<https://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/>),
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.

Post by Richard Hodges
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]

Post by Richard Hodges
The only way to increase the productivity of a c++ engineer to match that

Post by Richard Hodges
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.

[Matthew Woehlke]

Post by Paul "TBBle" Hampson

Post by Richard Hodges
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

[Nicol Bolas]

Post by Matthew Woehlke

Post by Paul "TBBle" Hampson

Post by Richard Hodges
The only way to increase the productivity of a c++ engineer to match

that

Post by Paul "TBBle" Hampson

Post by Richard Hodges
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

Post by Paul "TBBle" Hampson
hunting down the appropriate libraries to get useful work done. Is it

the

Post by Paul "TBBle" Hampson
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
$ 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/

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.

Post by Matthew Woehlke
--
Matthew

[Richard Hodges]

it's that it is unreasonable to expect the C++ standards committee to be

able to do anything about it.

Post by Hyman Rosen

Post by Paul "TBBle" Hampson

Post by Richard Hodges
The only way to increase the productivity of a c++ engineer to match

that

Post by Paul "TBBle" Hampson

Post by Richard Hodges
of a Java or Javascript dev is to give him comparably useful,

standard,

Post by Paul "TBBle" Hampson

Post by Richard Hodges
tools.

Why is that? Java and Javascript development *also* require going out

and

Post by Paul "TBBle" Hampson
hunting down the appropriate libraries to get useful work done. Is it

the

Post by Paul "TBBle" Hampson
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
$ 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/

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.

Post by Hyman Rosen
--
Matthew

--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[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++?

it's that it is unreasonable to expect the C++ standards committee to

be able to do anything about it.

Post by Hyman Rosen

Post by Paul "TBBle" Hampson

Post by Richard Hodges
The only way to increase the productivity of a c++ engineer to match

that

Post by Paul "TBBle" Hampson

Post by Richard Hodges
of a Java or Javascript dev is to give him comparably useful,

standard,

Post by Paul "TBBle" Hampson

Post by Richard Hodges
tools.

Why is that? Java and Javascript development *also* require going out

and

Post by Paul "TBBle" Hampson
hunting down the appropriate libraries to get useful work done. Is it

the

Post by Paul "TBBle" Hampson
existence of npm and Maven (is that right?) that makes the

productivity

Post by Paul "TBBle" Hampson
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
$ 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/

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.

Post by Hyman Rosen
--
Matthew

--
---
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
Visit this group at https://groups.google.com/a/is
ocpp.org/group/std-discussion/.

[Matthew Woehlke]

Post by Nicol Bolas

Post by Matthew Woehlke
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/

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.

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.)

Post by Nicol Bolas
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

[Richard Hodges]

Post by Paul "TBBle" Hampson
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.

Post by Paul "TBBle" Hampson
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 :)

Post by Paul "TBBle" Hampson

Post by Richard Hodges
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
<https://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/>),
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.

Post by Richard Hodges
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Ricardo Fabiano de Andrade]

Post by Matthew Woehlke

Post by Ricardo Fabiano de Andrade
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!

Post by Matthew Woehlke
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

Post by Matthew Woehlke
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.

Post by Matthew Woehlke

Post by Ricardo Fabiano de Andrade
2) Stop using std::experimental and instead use std::alpha / std::beta

(or

Post by Ricardo Fabiano de Andrade
anything that indicates how close such feature is to the final standard).
Companies/teams would be more comfortable adopting and testing

pre-standard

Post by Ricardo Fabiano de Andrade
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.

Post by Matthew Woehlke
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.

Post by Matthew Woehlke
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.

Post by Matthew Woehlke

Post by Ricardo Fabiano de Andrade
3) Library proposals should have standard implementations which compile

in

Post by Ricardo Fabiano de Andrade
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.

Post by Matthew Woehlke
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.

Post by Matthew Woehlke
--
Matthew
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Matthew Woehlke]

Post by Ricardo Fabiano de Andrade

Post by Matthew Woehlke
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

[Ricardo Fabiano de Andrade]

Post by Matthew Woehlke

Post by Ricardo Fabiano de Andrade

Post by Matthew Woehlke
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.

Post by Ricardo Fabiano de Andrade
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

Post by Ricardo Fabiano de Andrade
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.

Post by Matthew Woehlke
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.

Post by Matthew Woehlke
--
Matthew
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Michael Kilburn]

Post by Ricardo Fabiano de Andrade
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.

Post by Ricardo Fabiano de Andrade
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.
- 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).


2) Stop using std::experimental and instead use std::alpha / std::beta (or

Post by Ricardo Fabiano de Andrade
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
- 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
- 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? :)

:-)

[Matthew Woehlke]

[...] 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

[Nevin Liber]

On Thu, Sep 14, 2017 at 2:48 PM, Ville Voutilainen <

Post by Ville Voutilainen
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>

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

+1
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[i***@gmail.com]

Post by Nicol Bolas
Many of the libraries you're talking about are big; much larger than

most SO questions or answers.... etc
This is reducto ad absurdum.
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' via ISO C++ Standard - Discussion]

Post by Nicol Bolas

Post by Richard Hodges

Post by Nicol Bolas
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.

['Bruce Adams' via ISO C++ Standard - Discussion]

Post by Nicol Bolas
On Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges

Post by Richard Hodges

Post by Thiago Macieira

Post by Richard Hodges
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' via ISO C++ Standard - Discussion]

Post by 'Bruce Adams' via ISO C++ Standard - Discussion

Post by Nicol Bolas
On Wednesday, September 13, 2017 at 12:20:20 PM UTC-4, Richard Hodges

Post by Richard Hodges

Post by Thiago Macieira

Post by Richard Hodges
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.

Post by 'Bruce Adams' via ISO C++ Standard - 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.

[Victor Dyachenko]

Post by Howard Hinnant
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]

Post by Victor Dyachenko
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.

Post by Victor Dyachenko

Post by Howard Hinnant
This is a great example, and I think the beginning of a good guideline.
Don’t allow references to be returned from rvalues.

void eat(std::string_view );
eat(MakeCurrencyPair().base());
Perfectly safe.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Nicol Bolas]

Post by Richard Hodges

Post by Victor Dyachenko
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

Post by Richard Hodges

Post by Victor Dyachenko
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.

[Richard Hodges]

Post by Howard Hinnant
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.

Post by Howard Hinnant
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.

Post by Howard Hinnant
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

Post by Richard Hodges

Post by Victor Dyachenko
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&&.

Post by Richard Hodges
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.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.

[Ville Voutilainen]

Post by Richard Hodges

Post by Howard Hinnant
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.

Post by Richard Hodges
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.

Post by Richard Hodges
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.

Post by Richard Hodges
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.

[Nicol Bolas]

Post by Richard Hodges
There is another very pertinent case that you've missed, I'll get to that
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.
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.

Perhaps, but does the user know if the function takes a `string` or a
`string_view`? Equally importantly, does the user *care* about such
trivialities?

Also, the UDL version doesn't have to call `char_traits<>::length` to get
the length, since it's known at compile-time, so I have a hard time calling
that a "pessimisation". Oh sure, many compilers may optimize that away. But
I prefer code that compilers don't have to have special-case optimizations
for. Or at least, ones where special-case optimizations are unnecessary.

Oh sure, the `sv` literal would be best. But we can easily replace that
expression with some function that returns a `string`. The point is that
calling that function with a prvalue of type `string`, is always functional
code.

another would be

Post by Richard Hodges
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.

How does that *not* "impede readability"? It adds needless verbiage to what
was otherwise quite succinct: I am passing a string to a function.
"Needless verbiage" always impede readability.

Of the 4 alternatives, some_func("a string"s); is the least optimised and

Post by Richard Hodges
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.

This is not backwards compatible in any way, shape, or form. And I'm not
talking about in subtle ways like you're talking about.

If I'm using this library, and I store the returned string into my own
string class, I probably have an implicit conversion from `std::string` to
my class. Well, since `string_view` is new, I *don**'t* have an implicit
conversion from that. So all of my code is broken now.

Changes that are not backwards compatible changes are *not backwards
compatible*.

(in the naive mind of the maintainer, fresh out of university), perhaps

Post by Richard Hodges
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.
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.

Stop making breaking changes with the expectation that they're not breaking
changes, and you will stop having UB.

My regression tests may even pass perfectly, because of course my

Post by Richard Hodges
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.

... huh? The example you provide here has *nothing* to do with implicit
conversion. This doesn't fail because `string` is implicitly convertible to
`string_view`. It fails because you're getting a reference to a destroyed
object. Making the conversion explicit would change absolutely nothing
about the code here.

Because it's UB waiting to happen in code that was working and now is not.

Post by Richard Hodges
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..."

We cannot help that people will write bad code. We can only give them the
tools to write good code. `string_view` is a tool that makes lots of good,
efficient, and most importantly *inter-operable* code possible. Can it be
used badly? Sure. But we can't help that.

And with that, I feel I have given the committee and the c++ community fair

Post by Richard Hodges
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.

... we were? I was completely unaware of that. I thought we were getting
rid of *owning* raw pointers. `string_view`, by its very name, does not
bestow ownership.

Post by Richard Hodges
For shame.

[Matthew Woehlke]

Post by Nicol Bolas
The question ultimately comes down to two pieces of code.
void some_func(string_view s);
some_func("a string"s);
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.

Post by Nicol Bolas
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.)

Post by Nicol Bolas
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]

Post by Matthew Woehlke
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.

[Thiago Macieira]

Post by o***@gmail.com
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

[Nevin Liber]

Post by o***@gmail.com
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).

Post by o***@gmail.com
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.

Post by o***@gmail.com
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.

Post by o***@gmail.com
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.

Post by o***@gmail.com
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.

Post by o***@gmail.com
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).

Post by o***@gmail.com
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:***@eviloverlord.com> [phone]
<(847)%20691-1404>