[std-discussion] Arguments against not allowing uninitializing variables

[a***@gmail.com]

Guys, I'm not sure if we agree on that but I think that uninitialized
variables in most cases are bad. There are few scenarios that there is
desirable not to have variable initialized like for example large buffer
which we will be reading to in next line, but apart from those few
examples, having uninitialized variables isn't something that I would like
to come across.

What would be arguments against such behavior:

Having uninitialized variables in form:

char a[100];

would be treated as an error. In order for having this uninitialized user
would have to say it explicitly:

char a[100] = delete;

Looking forward to hear your opinions

[Ville Voutilainen]

Post by a***@gmail.com
char a[100];
would be treated as an error. In order for having this uninitialized user
char a[100] = delete;

Has been suggested many times, breaks tons of (valid and reasonable) code,
is a complete non-starter for compatibility reasons.

[a***@gmail.com]

Do you have any resources that will confirm that?

Post by Ville Voutilainen

Post by a***@gmail.com
char a[100];
would be treated as an error. In order for having this uninitialized

user

Post by a***@gmail.com
char a[100] = delete;

Has been suggested many times, breaks tons of (valid and reasonable) code,
is a complete non-starter for compatibility reasons.

[a***@gmail.com]

And again, if it breaks that code it either means that they use (legally
and responsibly) lots of uninitialized variables. In that case this rule
would help them clarify their code. Other scenario is that their are using
variables that are used without being initialized. In that case that would
help find bugs in their code.

Post by a***@gmail.com
Do you have any resources that will confirm that?

Post by Ville Voutilainen

Post by a***@gmail.com
char a[100];
would be treated as an error. In order for having this uninitialized

user

Post by a***@gmail.com
char a[100] = delete;

Has been suggested many times, breaks tons of (valid and reasonable) code,
is a complete non-starter for compatibility reasons.

[Thiago Macieira]

Post by a***@gmail.com
And again, if it breaks that code it either means that they use (legally
and responsibly) lots of uninitialized variables. In that case this rule
would help them clarify their code. Other scenario is that their are using
variables that are used without being initialized. In that case that would
help find bugs in their code.

And compilers already help identifying use of uninitialised data.

Another thing to note is that your syntax cannot delete the call to
constructors:

struct S
{
S();
int i, j, k;
};

void f()
{
S s = delete; // irrelevant, since the constructor MUST be called
cin >> s;
}

And even if the constructor is called, there's no guarantee that it did
initialise everything. The body for S::S() could be in another translation
unit and could do:

S::S() : i(0) {}

The only way to catch those is with a good compiler doing link-time code
generation or with a runtime memory profiler like Valgrind.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[a***@gmail.com]

I somewhat disagree with your statement.

S s = delete; // irrelevant, since the constructor MUST be called

Why must? Why can't we introduce rule that the above statement means ctor
is not being called?

Post by Thiago Macieira

Post by a***@gmail.com
And again, if it breaks that code it either means that they use (legally
and responsibly) lots of uninitialized variables. In that case this rule
would help them clarify their code. Other scenario is that their are

using

Post by a***@gmail.com
variables that are used without being initialized. In that case that

would

Post by a***@gmail.com
help find bugs in their code.

And compilers already help identifying use of uninitialised data.
Another thing to note is that your syntax cannot delete the call to
struct S
{
S();
int i, j, k;
};
void f()
{
S s = delete; // irrelevant, since the constructor MUST be
called
cin >> s;
}
And even if the constructor is called, there's no guarantee that it did
initialise everything. The body for S::S() could be in another translation
S::S() : i(0) {}
The only way to catch those is with a good compiler doing link-time code
generation or with a runtime memory profiler like Valgrind.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Ville Voutilainen]

Post by a***@gmail.com
I somewhat disagree with your statement.
S s = delete; // irrelevant, since the constructor MUST be called
Why must? Why can't we introduce rule that the above statement means ctor is
not being called?

You're suggesting that that code must throw an exception?

[a***@gmail.com]

Sorry, I don't understand, throw exception where it sees this line:

S s = delete; // irrelevant, since the constructor MUST be called
or throw exception when it sees this line:
S s;

Post by Thiago Macieira

Post by a***@gmail.com
I somewhat disagree with your statement.
S s = delete; // irrelevant, since the constructor MUST be called
Why must? Why can't we introduce rule that the above statement means

ctor is

Post by a***@gmail.com
not being called?

You're suggesting that that code must throw an exception?

[a***@gmail.com]

No, I'm not suggesting that.

Post by Thiago Macieira

Post by a***@gmail.com
I somewhat disagree with your statement.
S s = delete; // irrelevant, since the constructor MUST be called
Why must? Why can't we introduce rule that the above statement means

ctor is

Post by a***@gmail.com
not being called?

You're suggesting that that code must throw an exception?

[Ville Voutilainen]

Post by a***@gmail.com
No, I'm not suggesting that.

What, then? The program is supposed to skip a constructor that the
user explicitly
stated can not be skipped?

[a***@gmail.com]

Yes I see your point. What about rule that all built in types must not be
left uninitialized? That would I believe solved all those problems?

Post by Ville Voutilainen

Post by a***@gmail.com
No, I'm not suggesting that.

What, then? The program is supposed to skip a constructor that the
user explicitly
stated can not be skipped?

[Ville Voutilainen]

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not be
left uninitialized? That would I believe solved all those problems?

How are these new rule complications any better than the current rules?

[a***@gmail.com]

These new rules enforce code correctness. AFAIC having uninitialized
variables is almost always a mistake.

Post by Ville Voutilainen

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not

be

Post by a***@gmail.com
left uninitialized? That would I believe solved all those problems?

How are these new rule complications any better than the current rules?

[Cleiton Santoia]

First question :

Do you think it's worth the effort to C++ community to adapt to this idea ?

Post by a***@gmail.com
These new rules enforce code correctness. AFAIC having uninitialized
variables is almost always a mistake.

Post by Ville Voutilainen

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not

be

Post by a***@gmail.com
left uninitialized? That would I believe solved all those problems?

How are these new rule complications any better than the current rules?

[Casey Carter]

Post by a***@gmail.com
These new rules enforce code correctness. AFAIC having uninitialized
variables is almost always a mistake.

Not initializing an object is sometimes a mistake. Accessing the value of
an uninitialized object is *always* a mistake; it's a programming error
that tools can help us discover. Changing the language to always
value-initialize objects changes what was previously undefined behavior
into defined behavior, but it doesn't fix the programming error. In fact it
makes such errors harder for tools to detect. Your proposed rules do not
"enforce code correctness" since unintended behavior is likely incorrect
whether or not that behavior is defined.

If your goal is to make it harder/impossible to unintentionally access the
value of an uninitialized object, I think there are ways to do so without
incompatible changes to the language that the committee would never
support. For example, a compiler flag that emits a diagnostic for objects
without explicit initializers - along with a possibly-standardized
attribute to explicitly suppress said diagnostic for objects intentionally
default-initialized - would achieve that same goal. And does so without any
breaking changes. I know I would find such a system useful, and I can't
imagine anyone on the committee opposing standardization of an attribute
that has absolutely no semantic effect.

[a***@gmail.com]

Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?

I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.

So question to the committee:

What are your plans to make C++ clean and easier to learn/use?

Post by Casey Carter

Post by a***@gmail.com
These new rules enforce code correctness. AFAIC having uninitialized
variables is almost always a mistake.

Not initializing an object is sometimes a mistake. Accessing the value of
an uninitialized object is *always* a mistake; it's a programming error
that tools can help us discover. Changing the language to always
value-initialize objects changes what was previously undefined behavior
into defined behavior, but it doesn't fix the programming error. In fact it
makes such errors harder for tools to detect. Your proposed rules do not
"enforce code correctness" since unintended behavior is likely incorrect
whether or not that behavior is defined.
If your goal is to make it harder/impossible to unintentionally access the
value of an uninitialized object, I think there are ways to do so without
incompatible changes to the language that the committee would never
support. For example, a compiler flag that emits a diagnostic for objects
without explicit initializers - along with a possibly-standardized
attribute to explicitly suppress said diagnostic for objects intentionally
default-initialized - would achieve that same goal. And does so without any
breaking changes. I know I would find such a system useful, and I can't
imagine anyone on the committee opposing standardization of an attribute
that has absolutely no semantic effect.

[Nevin Liber]

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.

What on earth are you talking about?

Casey Carter's point in the message you directly replied to is that your
proposed change makes it *harder*, not easier to use the language. Instead
of endlessly repeating your meaningless platitudes, why not try reading and
addressing the points that people are actually making instead of ignoring
them?

Post by a***@gmail.com

Post by Casey Carter

Post by a***@gmail.com
These new rules enforce code correctness. AFAIC having uninitialized
variables is almost always a mistake.

Not initializing an object is sometimes a mistake. Accessing the value of
an uninitialized object is *always* a mistake; it's a programming error
that tools can help us discover. Changing the language to always
value-initialize objects changes what was previously undefined behavior
into defined behavior, but it doesn't fix the programming error. In fact it
makes such errors harder for tools to detect. Your proposed rules do not
"enforce code correctness" since unintended behavior is likely incorrect
whether or not that behavior is defined.

--

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

[a***@gmail.com]

@Nevin
I did read them and I do understand them. And I admitted that his point is
fair by saying fair enough. So maybe you loose your attitude, stop being
unpleasant and try reading what I'm saying too?

Post by Nevin Liber

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.

What on earth are you talking about?
Casey Carter's point in the message you directly replied to is that your
proposed change makes it *harder*, not easier to use the language.
Instead of endlessly repeating your meaningless platitudes, why not try
reading and addressing the points that people are actually making instead
of ignoring them?

Post by a***@gmail.com

Post by Casey Carter

Post by a***@gmail.com
These new rules enforce code correctness. AFAIC having uninitialized
variables is almost always a mistake.

Not initializing an object is sometimes a mistake. Accessing the value
of an uninitialized object is *always* a mistake; it's a programming error
that tools can help us discover. Changing the language to always
value-initialize objects changes what was previously undefined behavior
into defined behavior, but it doesn't fix the programming error. In fact it
makes such errors harder for tools to detect. Your proposed rules do not
"enforce code correctness" since unintended behavior is likely incorrect
whether or not that behavior is defined.

--

691-1404

[Nicol Bolas]

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress.

The problem with your analogy is that it ignores the ramifications of your
proposal.

You've suggested that the next version of C++ should make the old default
initialization syntax illegal, instead using a new default initialization
syntax. And then you claim that this is the equivalent of claiming imminent
domain over a "picturesque village" in the country and bulldozing it.

The problem is that your analogy ignores the reality and magnitude of this
change. This change is much more like proposing to bulldoze *downtown New
York*.

Virtually every program in existence uses default initialization
*somewhere.* Which mean that your proposal will require that every C++
programmer, in order to use all of the other nifty language features of
C++17, must either manually fix all of their default initialization
scenarios or use an automated tool to do it.

Every C++ programmer. Every project that uses C++. Everywhere. To upgrade,
they *must* do this.

Now riddle me this: even if this somehow went through the committee, don't
you think that Microsoft, Intel, Clang, and GCC would implement a simple
compiler switch that would turn off this behavior? Or hell, considering how
much of a breaking change it is, they'd probably require a compiler switch
to *turn it on*.

And since virtually every project would use this setting by default...
whatever good this proposal might have achieved will never come to pass.

From a *practical* perspective, what you want is simply not possible. Not
without making up a whole other language.

Post by a***@gmail.com
But I do understand that this will not change as of now. Pity though.
What are your plans to make C++ clean and easier to learn/use?

There isn't one. To the degree that C++ is unclean or hard to learn, the
"plan" is to add features that, when used, make C++ cleaner or easier to
learn/use. When C++11 introduced smart pointers, they weren't a language
feature. You aren't *forced* to use them; they didn't invalidate naked
pointers. They are there for those who want that protection. But they're
optional.

That's how clean/easy C++ works: you use the parts of the langauge that are
clean and easy. You stay away from the parts that aren't.

That's the best you can do in a language that has as many lines of active
code in use as C++.

[a***@gmail.com]

Hi Nicol,
Yep, fair enough and I do see your point. But look at Tony's VE proposal
and tell me what your thinking about it.

Post by Nicol Bolas

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress.

The problem with your analogy is that it ignores the ramifications of your
proposal.
You've suggested that the next version of C++ should make the old default
initialization syntax illegal, instead using a new default initialization
syntax. And then you claim that this is the equivalent of claiming imminent
domain over a "picturesque village" in the country and bulldozing it.
The problem is that your analogy ignores the reality and magnitude of this
change. This change is much more like proposing to bulldoze *downtown New
York*.
Virtually every program in existence uses default initialization
*somewhere.* Which mean that your proposal will require that every C++
programmer, in order to use all of the other nifty language features of
C++17, must either manually fix all of their default initialization
scenarios or use an automated tool to do it.
Every C++ programmer. Every project that uses C++. Everywhere. To upgrade,
they *must* do this.
Now riddle me this: even if this somehow went through the committee, don't
you think that Microsoft, Intel, Clang, and GCC would implement a simple
compiler switch that would turn off this behavior? Or hell, considering how
much of a breaking change it is, they'd probably require a compiler switch
to *turn it on*.
And since virtually every project would use this setting by default...
whatever good this proposal might have achieved will never come to pass.
From a *practical* perspective, what you want is simply not possible. Not
without making up a whole other language.

Post by a***@gmail.com
But I do understand that this will not change as of now. Pity though.
What are your plans to make C++ clean and easier to learn/use?

There isn't one. To the degree that C++ is unclean or hard to learn, the
"plan" is to add features that, when used, make C++ cleaner or easier to
learn/use. When C++11 introduced smart pointers, they weren't a language
feature. You aren't *forced* to use them; they didn't invalidate naked
pointers. They are there for those who want that protection. But they're
optional.
That's how clean/easy C++ works: you use the parts of the langauge that
are clean and easy. You stay away from the parts that aren't.
That's the best you can do in a language that has as many lines of active
code in use as C++.

[Tony V E]

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.
What are your plans to make C++ clean and easier to learn/use?

If you really want to clean up stuff, I think the only way forward is a
long term - very long term - evolutionary plan. Like introduce some syntax
such as

int x = delete; // explicit uninit

But don't change any existing behaviour:

int y; // implicit uninit

is still OK. But with the new syntax available, compilers could start
issuing warnings about the old syntax. Developers can choose whether they
want those warnings or not.
Likely those warnings start as OFF by default, but eventually (years)
compilers start shipping with them ON by default.

Some day (10 - 15 years) you can deprecate "implicit uninit" in the
standard.
Some day later (now 20 + years) you can make it an error.

I think that is the only way forward for cleaning up the language. You
need an "evolutionary path".

So for any proposal/suggestion we would need to decide:

0. do we want to be there _eventually_ - ie Is the proposal sound? Do we
wish we had a time machine?
1. is there an evolutionary path to get there? (not always possible!)
2. it it worth the trouble?

Tony

[David Rodríguez Ibeas]

I sometimes wonder how much leeway do compilers have to use attributes for
extensions... A compiler could have an extension to zero-initialize before
default-initialization unless the user identified the variable as
[[uninitialized]], for example:

int x;
assert(x == 0);
[[uninitialized]] int array[LARGE_SIZE];
// cannot assert anything at this point

cc --zero-init test.cpp

At any rate, whether this is a valid use of attributes or not, this is more
of the job of the compiler than the standard. Compilers nowadays are able
to warn in many cases when a variable is used uninitialized. They not
always succeed, but I don't recall the last time I encountered this as a
bug in production.

David

Post by Tony V E

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.
What are your plans to make C++ clean and easier to learn/use?

If you really want to clean up stuff, I think the only way forward is a
long term - very long term - evolutionary plan. Like introduce some syntax
such as
int x = delete; // explicit uninit
int y; // implicit uninit
is still OK. But with the new syntax available, compilers could start
issuing warnings about the old syntax. Developers can choose whether they
want those warnings or not.
Likely those warnings start as OFF by default, but eventually (years)
compilers start shipping with them ON by default.
Some day (10 - 15 years) you can deprecate "implicit uninit" in the
standard.
Some day later (now 20 + years) you can make it an error.
I think that is the only way forward for cleaning up the language. You
need an "evolutionary path".
0. do we want to be there _eventually_ - ie Is the proposal sound? Do we
wish we had a time machine?
1. is there an evolutionary path to get there? (not always possible!)
2. it it worth the trouble?
Tony
--
---
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
http://groups.google.com/a/isocpp.org/group/std-discussion/.

[a***@gmail.com]

Hi guys, I'd really like to thank you all of you for your input.

Tony VE, I have to say that I fell in love with your idea. It is I believe
best non-intrusive options and yes, I'm happy to wait for change if that
change is decided to be.
So could we please really consider it as an option? That is, lets make
future C++ a clean and easy to use language. I believe that it is better
than simply not doing anything about it and accept the current status as a
status quo?

What are your thoughts on that?

Post by Tony V E

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.
What are your plans to make C++ clean and easier to learn/use?

If you really want to clean up stuff, I think the only way forward is a
long term - very long term - evolutionary plan. Like introduce some syntax
such as
int x = delete; // explicit uninit
int y; // implicit uninit
is still OK. But with the new syntax available, compilers could start
issuing warnings about the old syntax. Developers can choose whether they
want those warnings or not.
Likely those warnings start as OFF by default, but eventually (years)
compilers start shipping with them ON by default.
Some day (10 - 15 years) you can deprecate "implicit uninit" in the
standard.
Some day later (now 20 + years) you can make it an error.
I think that is the only way forward for cleaning up the language. You
need an "evolutionary path".
0. do we want to be there _eventually_ - ie Is the proposal sound? Do we
wish we had a time machine?
1. is there an evolutionary path to get there? (not always possible!)
2. it it worth the trouble?
Tony

[Nicol Bolas]

Post by Tony V E

Post by a***@gmail.com
Fair enough. But I just wonder, how long can we carry on constantly
carrying on said baggage of old code. What about new code, not written yet?
Why don't we make something that would allow us to write better code from
the beginning?
I understand that the current trend in committee's policy is not to break
old code for any price. I'm really not sure if at some time this is simply
unwise. You cannot build highways and yet have untouched country side with
picturesque villages all around completely untouched. At some point some of
those villages must go in order for majority to progress. But I do
understand that this will not change as of now. Pity though.
What are your plans to make C++ clean and easier to learn/use?

If you really want to clean up stuff, I think the only way forward is a
long term - very long term - evolutionary plan. Like introduce some syntax
such as
int x = delete; // explicit uninit
int y; // implicit uninit
is still OK. But with the new syntax available, compilers could start
issuing warnings about the old syntax. Developers can choose whether they
want those warnings or not.
Likely those warnings start as OFF by default, but eventually (years)
compilers start shipping with them ON by default.
Some day (10 - 15 years) you can deprecate "implicit uninit" in the
standard.
Some day later (now 20 + years) you can make it an error.
I think that is the only way forward for cleaning up the language. You
need an "evolutionary path".
0. do we want to be there _eventually_ - ie Is the proposal sound? Do we
wish we had a time machine?
1. is there an evolutionary path to get there? (not always possible!)
2. it it worth the trouble?
Tony

The problem with the "evolutionary path" approach is that the standards
committee is notoriously *lazy* about these things.

Remember 'final' and 'override'? Well, they were part of an entire package
designed to make derived classes much safer to implement. There was going
to be a mechanism to decorate a class definition so that the compiler would
*enforce* the usage of 'override' for virtual functions that were meant to
override base class virtuals. And similar constructs, all intended to
ensure more safety in this domain.

This was reduced to just 'final' and 'override'. While they're certainly
useful, they lost the specific construct that would enforce their use. That
was postponed, to be added in a later revision.

Is it in C++14? Nope. Is there even a single proposal to stick it into
C++17? Nope. That's what happens in an "evolutionary path".

Something similar happened with "uniform initialization". It was intended
to be a way to uniformly initialize every type. Except... it's unsafe in
template situations, thanks to the preference for initializer_list
constructors (if you're not trying to call them). There's even a defect
about it with regard to std:;allocator::construct, which ought to be able
to use its parameter list as though it were a braced-init-list for
aggregate initialization, but can't use that syntax *uniformly*, again
because it would preference initializer_list constructors if all of the
elements are of the same type. So the resolution for the defect requires
template metaprogramming SFINAE trickery to detect if the object has a
suitable constructor, etc.

This was an "evolutionary step" away from the wide variety of
initialization. Initialization became more uniform, but there are still
exceptions that you have to teach users. Have there been any proposals to
correct this? Nope. Has the committee expressed interest in taking some
next "evolutionary" step to getting actually *uniform* initialization?
Quite the opposite; those who comment on the issue say there's nothing
wrong. Just change your class's constructors to avoid the problem, even
though we won't change the *standard library* to avoid it.

We'll likely see something similar with concepts. Oh, we'll get checking at
instantation time. But checking expressions within the template
implementation, to see if they conform to the requirements of the concept?
That's too hard. Concept mapping? Nope, too hard.

In general, when I hear people talking about an "evolutionary path", what I
translate that to is, "We won't *actually* fix the problem. We'll solve *just
enough* of the problem to get you to shut up, then hope you'll go away
before you make us do the hard part."

If there's no commitment or follow-through by the committee on the
"evolutionary path", I'd really rather they just not bother. The explicit
defaut-initialization syntax only adds another thing to the language.

[Ville Voutilainen]

Post by Nicol Bolas
The problem with the "evolutionary path" approach is that the standards
committee is notoriously lazy about these things.

We are more than eager to welcome hard-working individuals who are
willing to write and champion proposals and implement prototypes.
If you think you can do that, by all means do. In the meanwhile, feel free
to stop calling people doing volunteer work "lazy", such terms give a strong
indication that you have no idea what you're talking about.

Post by Nicol Bolas
Remember 'final' and 'override'? Well, they were part of an entire package
designed to make derived classes much safer to implement. There was going to

Final was never part of that "package". And while that package was in the
original proposal, it was streamlined, then resurrected, and streamlined again.
There was no request to resurrect the full package, but there was a request
to add override alongside final, with a specific recommendation not to add
further complexity.

Post by Nicol Bolas
be a mechanism to decorate a class definition so that the compiler would
enforce the usage of 'override' for virtual functions that were meant to
override base class virtuals. And similar constructs, all intended to ensure
more safety in this domain.

And we already have implementation warnings that suggest adding the override
keyword were applicable. They allow for that increased safety that you seek for.

Post by Nicol Bolas
This was reduced to just 'final' and 'override'. While they're certainly

Yes, for very good reasons. The "check if annotations are not in place"
facility needs to be absolutely right the moment it's added, because
any tweak to it break existing uses of it.

Post by Nicol Bolas
useful, they lost the specific construct that would enforce their use. That
was postponed, to be added in a later revision.

To be _potentially_ added in a later revision _if_ someone does the work.

Post by Nicol Bolas
Is it in C++14? Nope. Is there even a single proposal to stick it into
C++17? Nope. That's what happens in an "evolutionary path".

That's what happens when nobody feels strong enough about a facility
to make it work.

Post by Nicol Bolas
Something similar happened with "uniform initialization". It was intended to
be a way to uniformly initialize every type. Except... it's unsafe in
template situations, thanks to the preference for initializer_list
constructors (if you're not trying to call them). There's even a defect
about it with regard to std:;allocator::construct, which ought to be able to
use its parameter list as though it were a braced-init-list for aggregate
initialization, but can't use that syntax uniformly, again because it would
preference initializer_list constructors if all of the elements are of the
same type. So the resolution for the defect requires template
metaprogramming SFINAE trickery to detect if the object has a suitable
constructor, etc.

Yes, that's the current proposal to allow aggregates to work with the library
factory functions. Do you have a superior solution?

Post by Nicol Bolas
This was an "evolutionary step" away from the wide variety of
initialization. Initialization became more uniform, but there are still
exceptions that you have to teach users. Have there been any proposals to
correct this? Nope. Has the committee expressed interest in taking some next
"evolutionary" step to getting actually uniform initialization? Quite the
opposite; those who comment on the issue say there's nothing wrong. Just
change your class's constructors to avoid the problem, even though we won't
change the standard library to avoid it.

We have never said "we won't change the standard library", that's why the issue
is still open and some of us are actively working on it.

Post by Nicol Bolas
We'll likely see something similar with concepts. Oh, we'll get checking at
instantation time. But checking expressions within the template
implementation, to see if they conform to the requirements of the concept?
That's too hard. Concept mapping? Nope, too hard.

By all means show how to do it.

Post by Nicol Bolas
In general, when I hear people talking about an "evolutionary path", what I
translate that to is, "We won't actually fix the problem. We'll solve just
enough of the problem to get you to shut up, then hope you'll go away before
you make us do the hard part."

"Before you make us do..."? That's rich. Many people posting
on this forum are far from the point of making the committee do anything,
since they don't exactly follow through on their complaints, other than
repeating their complaints.

Post by Nicol Bolas
If there's no commitment or follow-through by the committee on the
"evolutionary path", I'd really rather they just not bother. The explicit
defaut-initialization syntax only adds another thing to the language.

Oh, I do agree tha we shouldn't bother with explicit
default-initialization syntax.
That's not because the evolutionary path in general wouldn't work process-wise,
but because I don't think that path leads anywhere in this case.

[a***@gmail.com]

Post by Ville Voutilainen
Oh, I do agree tha we shouldn't bother with explicit
default-initialization syntax.
That's not because the evolutionary path in general wouldn't work process-wise,
but because I don't think that path leads anywhere in this case.

It leads to C++ which is cleaner and easier to use in the future.

[Ville Voutilainen]

Post by a***@gmail.com

Post by Ville Voutilainen
Oh, I do agree tha we shouldn't bother with explicit
default-initialization syntax.
That's not because the evolutionary path in general wouldn't work process-wise,
but because I don't think that path leads anywhere in this case.

It leads to C++ which is cleaner and easier to use in the future.

Based on what? The only direction such a change would seemingly lead to
is adding a way to say "I'm not doing value-initialization", with no chance to
change the existing default-initialization syntax to do
value-initialization instead.
People who believe the latter is possible are seriously mistaken,
since in addition
to being a breaking change to existing C++ code, it would also create
a C incompatibility
without any remedy, since C is unlikely to adopt such a change.

[a***@gmail.com]

This is not a breaking change. Read again Tony's VE post.

Post by Ville Voutilainen

Post by a***@gmail.com

Post by Ville Voutilainen
Oh, I do agree tha we shouldn't bother with explicit
default-initialization syntax.
That's not because the evolutionary path in general wouldn't work process-wise,
but because I don't think that path leads anywhere in this case.

It leads to C++ which is cleaner and easier to use in the future.

Based on what? The only direction such a change would seemingly lead to
is adding a way to say "I'm not doing value-initialization", with no chance to
change the existing default-initialization syntax to do
value-initialization instead.
People who believe the latter is possible are seriously mistaken,
since in addition
to being a breaking change to existing C++ code, it would also create
a C incompatibility
without any remedy, since C is unlikely to adopt such a change.

[Cleiton Santoia]

ÂŽ
Why donÂŽt you a "safe_basic_type.h" header file ? with a "safe int" class ?




Cleiton

Post by a***@gmail.com
This is not a breaking change. Read again Tony's VE post.

Post by Ville Voutilainen

Post by a***@gmail.com

Post by Ville Voutilainen
Oh, I do agree tha we shouldn't bother with explicit
default-initialization syntax.
That's not because the evolutionary path in general wouldn't work process-wise,
but because I don't think that path leads anywhere in this case.

It leads to C++ which is cleaner and easier to use in the future.

Based on what? The only direction such a change would seemingly lead to
is adding a way to say "I'm not doing value-initialization", with no chance to
change the existing default-initialization syntax to do
value-initialization instead.
People who believe the latter is possible are seriously mistaken,
since in addition
to being a breaking change to existing C++ code, it would also create
a C incompatibility
without any remedy, since C is unlikely to adopt such a change.

[Cleiton Santoia]

Why donÂŽt you ***build*** a "safe_basic_type.h" header file ? with a "safe
int" class ?

sorry for typo.

Cleiton

Em quarta-feira, 18 de março de 2015 15:57:37 UTC-3, Cleiton Santoia

Post by Cleiton Santoia
ÂŽ
Why donÂŽt you a "safe_basic_type.h" header file ? with a "safe int" class ?
Cleiton

Post by a***@gmail.com
This is not a breaking change. Read again Tony's VE post.

Post by Ville Voutilainen

Post by a***@gmail.com

Post by Ville Voutilainen
Oh, I do agree tha we shouldn't bother with explicit
default-initialization syntax.
That's not because the evolutionary path in general wouldn't work process-wise,
but because I don't think that path leads anywhere in this case.

It leads to C++ which is cleaner and easier to use in the future.

Based on what? The only direction such a change would seemingly lead to
is adding a way to say "I'm not doing value-initialization", with no chance to
change the existing default-initialization syntax to do
value-initialization instead.
People who believe the latter is possible are seriously mistaken,
since in addition
to being a breaking change to existing C++ code, it would also create
a C incompatibility
without any remedy, since C is unlikely to adopt such a change.

[Cleiton Santoia]

Mr Atch, I donÂŽt know if you deserve that, but I took longs 10 minutes out
of my life to make this, please enjoy your safety.

http://coliru.stacked-crooked.com/a/06c56ec211cfd06b


Att
Cleiton

[a***@gmail.com]

And why wouldn't I "deserve" that? Why are you being unpleasant and rude?

Post by Cleiton Santoia
Mr Atch, I donÂŽt know if you deserve that, but I took longs 10 minutes out
of my life to make this, please enjoy your safety.
http://coliru.stacked-crooked.com/a/06c56ec211cfd06b
Att
Cleiton

[Ville Voutilainen]

Post by a***@gmail.com
This is not a breaking change. Read again Tony's VE post.

Perhaps you should read what I wrote. I didn't refer to adding =noinit
or some such as a breaking change, but the apparent planned follow-up
along the evolutionary path.

[Nevin Liber]

Post by Nicol Bolas
The problem with the "evolutionary path" approach is that the standards
committee is notoriously *lazy* about these things.

We are? I take offense at that.

Post by Nicol Bolas
Remember 'final' and 'override'? Well, they were part of an entire package
designed to make derived classes much safer to implement. There was going
to be a mechanism to decorate a class definition so that the compiler would
*enforce* the usage of 'override' for virtual functions that were meant
to override base class virtuals. And similar constructs, all intended to
ensure more safety in this domain.

The committee works on proposals. If the people who were passionate about
those features are no longer passionate enough about them to present a
proposal addressing all the concerns that came up, well, what should the
committee do? Get volunteers to somehow work on stuff no one thinks is a
priority? People would then complain, probably on this very list, that we
are wasting our time.

And if you think this is so darn important, why aren't you doing the work?
If you believe we should get volunteers to do this work, then I nominate
you as that volunteer.

On the flip side, people were passionate about removing trigraphs,
auto_ptr, random_shuffle, unary_function, binary_function, ptr_fun, mem_fun
and mem_fun_ref, and they will be gone as of C++17.

Post by Nicol Bolas
We'll likely see something similar with concepts. Oh, we'll get checking
at instantation time. But checking expressions within the template
implementation, to see if they conform to the requirements of the concept?
That's too hard. Concept mapping? Nope, too hard.

I look forward to seeing your proposal and implementation proving this
wrong.

Post by Nicol Bolas
In general, when I hear people talking about an "evolutionary path", what
I translate that to is, "We won't *actually* fix the problem. We'll solve *just
enough* of the problem to get you to shut up, then hope you'll go away
before you make us do the hard part."

In general, whining on an email list about is easy; writing and revising
proposals and coming to multiple meetings to push them through is the hard
part and not at all lazy.

Post by Nicol Bolas
If there's no commitment or follow-through by the committee on the
"evolutionary path", I'd really rather they just not bother.

Do you feel the same way about people who spend their time griping on
mailing lists instead of committing and following through to writing and
championing actual proposals?
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[Nicol Bolas]

Post by Nevin Liber

Post by Nicol Bolas
The problem with the "evolutionary path" approach is that the standards
committee is notoriously *lazy* about these things.

We are? I take offense at that.

Post by Nicol Bolas
Remember 'final' and 'override'? Well, they were part of an entire
package designed to make derived classes much safer to implement. There was
going to be a mechanism to decorate a class definition so that the compiler
would *enforce* the usage of 'override' for virtual functions that were
meant to override base class virtuals. And similar constructs, all intended
to ensure more safety in this domain.

The committee works on proposals. If the people who were passionate about
those features are no longer passionate enough about them to present a
proposal addressing all the concerns that came up, well, what should the
committee do? Get volunteers to somehow work on stuff no one thinks is a
priority? People would then complain, probably on this very list, that we
are wasting our time.
And if you think this is so darn important, why aren't you doing the
work? If you believe we should get volunteers to do this work, then I
nominate you as that volunteer.
On the flip side, people were passionate about removing trigraphs,
auto_ptr, random_shuffle, unary_function, binary_function, ptr_fun, mem_fun
and mem_fun_ref, and they will be gone as of C++17.

Post by Nicol Bolas
We'll likely see something similar with concepts. Oh, we'll get checking
at instantation time. But checking expressions within the template
implementation, to see if they conform to the requirements of the concept?
That's too hard. Concept mapping? Nope, too hard.

I look forward to seeing your proposal and implementation proving this
wrong.

Post by Nicol Bolas
In general, when I hear people talking about an "evolutionary path", what
I translate that to is, "We won't *actually* fix the problem. We'll
solve *just enough* of the problem to get you to shut up, then hope
you'll go away before you make us do the hard part."

In general, whining on an email list about is easy; writing and revising
proposals and coming to multiple meetings to push them through is the hard
part and not at all lazy.

Post by Nicol Bolas
If there's no commitment or follow-through by the committee on the
"evolutionary path", I'd really rather they just not bother.

Do you feel the same way about people who spend their time griping on
mailing lists instead of committing and following through to writing and
championing actual proposals?
--

I don't think I explained myself very well. Perhaps a counter-example is in
order. That is, an example of the committee *not* being lazy.

Consider Herb Sutter's idea for a standardized "Lightweight Drawing
Library". He issued an outline of what he wanted. The problem is that,
well, he doesn't know much about this sort of thing. However, he didn't
follow the standard committee process of, "Gee, I hope that someone comes
along and writes a proposal. And attends meetings. And gets feedback and
writes new versions of the proposal. For years. Until hopefully it makes it
through."

In his capacity as a member of the C++ standards committee (and a major
person in the C++ scene), he actually sought out experts in this domain. He
went out and found people to write a proposal. He used his influence to cut
through the general red tape that surrounds committee proposals and ensure
that this would actually happen.

To be sure, it's not done yet. But my point is this. This isn't like
Stroustrup and concepts; there, he is the primary designer of the feature
as well as the one with the will to see it done. Herb took on the
responsibility, not to develop the feature, but to see to it that the
feature *gets developed*. He's pushing for it, and he will continue to do
so. If the current guys become disinterested, Herb will find someone else
to carry on.

The members of the standards committee should be doing more than just
reacting to proposals. They need to be actively trying to develop specific
features that improve C++ in various ways. They should be looking at where
C++ is deficient and working to resolve those deficiencies.

The study groups are one way, but they are too reactive. Study groups are
formed due to a critical mass of expertise on a complex subject. They
aren't formed in advance of such a critical mass; they aren't formed to
*create* such a critical mass. There's no process for actually creating
such a state.

The committee should have initiatives like Herb's, drives to push towards
some specific end. The committee's current process only reacts to
proposals; it doesn't proactively seek out solutions to specific C++
problems. What Herb did is the exception rather than the rule.

I consider this passive approach to be lazy: it puts all of the work is on
the *proposer*, not the committee. Even the desire for the feature is on
the proposer, not the committee (even if the proposer happens to be on the
committee). If the proposer doesn't show up after the commentary on the
proposer, then it just doesn't get done.

My favorite example of this is the proposal for Unicode library support in
C++. It was pretty comprehensive, ranging from specialized iterators to
string types, with Unicode normalization, and lots of other features. It
effectively died on the vine. There was a proposal, it was reviewed (IIRC,
the proposer wasn't able to attend, and had some trouble getting accurate
feedback about what happened), and... that was it. Eventually, despite
clearly having both an interest in the feature and some knowledge on the
subject, he just seemed to give it up as a bad job.

Unicode in C++ is an important problem. It is of sufficient importance that
the committee *itself* should have shown the initiative to make sure that
it gets solved. If one person didn't want to continue the proposal, another
interested expert should have been *sought out*, rather than them simply
waiting and hoping such a person would appear. The committee should have
been proactive in providing whatever support was needed to keep the
proposal moving and progressing. And if it wasn't progressing fast enough
or if the original person wanted to stop, the committee should have gone
out to find someone else to do it.

I see a lot of statements saying that there weren't enough/any proposals on
it, or that the proposer didn't come to meetings, or the proposer gave up
and it withered, or whatever. I hear a lot of talk from committee members
about welcoming proposals.

Yet I see little effort from them to actively seek them out. I see very
little *leadership* from the committee on several fronts in C++. I
mentioned Herb's example in part because it very much seems like the only
time I've seen someone on the committee take up a leadership role by
seeking out experts, rather than being one.

Maybe this is due to ISO rules or whatever. It doesn't really matter why
the status quo exists. What matters is that C++ is largely developed by
hoping that someone will manage to navigate the Byzantine process of
standardization with a proposal that accomplishes something useful. All
reactive, nothing proactive.

And so long as the committee remains non-proactive, there's no reason to
expect any "evolutionary path" to actually be followed. They'll adopt step
1, without any obligation or responsibility to even consider steps 2 or 3.

[Ville Voutilainen]

Post by Nicol Bolas
I don't think I explained myself very well. Perhaps a counter-example is in
order. That is, an example of the committee not being lazy.
Consider Herb Sutter's idea for a standardized "Lightweight Drawing
Library". He issued an outline of what he wanted. The problem is that, well,
he doesn't know much about this sort of thing. However, he didn't follow the
standard committee process of, "Gee, I hope that someone comes along and
writes a proposal. And attends meetings. And gets feedback and writes new
versions of the proposal. For years. Until hopefully it makes it through."
In his capacity as a member of the C++ standards committee (and a major
person in the C++ scene), he actually sought out experts in this domain. He
went out and found people to write a proposal. He used his influence to cut
through the general red tape that surrounds committee proposals and ensure
that this would actually happen.
To be sure, it's not done yet. But my point is this. This isn't like
Stroustrup and concepts; there, he is the primary designer of the feature as
well as the one with the will to see it done. Herb took on the
responsibility, not to develop the feature, but to see to it that the
feature gets developed. He's pushing for it, and he will continue to do so.
If the current guys become disinterested, Herb will find someone else to
carry on.
The members of the standards committee should be doing more than just
reacting to proposals. They need to be actively trying to develop specific
features that improve C++ in various ways. They should be looking at where
C++ is deficient and working to resolve those deficiencies.

Ah, like writing all the proposals that went into C++11 and C++14?

Post by Nicol Bolas
The study groups are one way, but they are too reactive. Study groups are
formed due to a critical mass of expertise on a complex subject. They aren't
formed in advance of such a critical mass; they aren't formed to create such
a critical mass. There's no process for actually creating such a state.

We have created study groups in advance of such a critical mass; in such
cases, the critical mass didn't form. The defunct Databases SG and
the Networking SG are examples of that.

Post by Nicol Bolas
The committee should have initiatives like Herb's, drives to push towards
some specific end. The committee's current process only reacts to proposals;
it doesn't proactively seek out solutions to specific C++ problems. What
Herb did is the exception rather than the rule.

Well, in the realm of networking, you got exactly what you want - even though
the SG didn't manage to go to the desired end goal, enough people inside
the committee pushed to get ASIO forward, including getting outside people
to help.

Post by Nicol Bolas
I consider this passive approach to be lazy: it puts all of the work is on
the proposer, not the committee. Even the desire for the feature is on the
proposer, not the committee (even if the proposer happens to be on the
committee). If the proposer doesn't show up after the commentary on the
proposer, then it just doesn't get done.

Well, work doesn't get done if nobody has the time and energy to do the
work. I don't see how the committee is supposed to magically solve such
a problem without any resources and any budget.

Post by Nicol Bolas
My favorite example of this is the proposal for Unicode library support in
C++. It was pretty comprehensive, ranging from specialized iterators to
string types, with Unicode normalization, and lots of other features. It
effectively died on the vine. There was a proposal, it was reviewed (IIRC,
the proposer wasn't able to attend, and had some trouble getting accurate
feedback about what happened), and... that was it. Eventually, despite
clearly having both an interest in the feature and some knowledge on the
subject, he just seemed to give it up as a bad job.
Unicode in C++ is an important problem. It is of sufficient importance that
the committee itself should have shown the initiative to make sure that it
gets solved. If one person didn't want to continue the proposal, another
interested expert should have been sought out, rather than them simply
waiting and hoping such a person would appear. The committee should have
been proactive in providing whatever support was needed to keep the proposal
moving and progressing. And if it wasn't progressing fast enough or if the
original person wanted to stop, the committee should have gone out to find
someone else to do it.

I'm curious as to with what means the committee is supposed to provide
"whatever support".

Post by Nicol Bolas
I see a lot of statements saying that there weren't enough/any proposals on
it, or that the proposer didn't come to meetings, or the proposer gave up
and it withered, or whatever. I hear a lot of talk from committee members
about welcoming proposals.
Yet I see little effort from them to actively seek them out. I see very

Gee, perhaps that's because people don't agree with you on the importance of it?

Post by Nicol Bolas
And so long as the committee remains non-proactive, there's no reason to
expect any "evolutionary path" to actually be followed. They'll adopt step
1, without any obligation or responsibility to even consider steps 2 or 3.

That part is correct.

[Tom Honermann]

Post by Nicol Bolas
My favorite example of this is the proposal for Unicode library support in
C++. It was pretty comprehensive, ranging from specialized iterators to
string types, with Unicode normalization, and lots of other features. It
effectively died on the vine. There was a proposal, it was reviewed (IIRC,
the proposer wasn't able to attend, and had some trouble getting accurate
feedback about what happened), and... that was it. Eventually, despite
clearly having both an interest in the feature and some knowledge on the
subject, he just seemed to give it up as a bad job.

I presume you are referring to N3572 [1]. My understanding is that the
committee rejected the approach of providing an additional string class. I
think this was the right decision. I don't think there have been any
further proposals since then.

I'm interested in improving Unicode support and have been working on
something for which I plan to submit a proposal Real Soon Now (pending
time/energy). It will just be a small step though, nothing comprehensive,
but it does avoid the yet-another-string-class approach. It is essentially
a view/range/iterator approach to enumerating code points in arbitrary
encodings. I hope to have it ready for Lenexa. Regardless of whether I'm
able to submit it for discussion there or not, I would be interested in
meeting with any interested parties to discuss improving Unicode support in
Lenexa. Anyone interested in such a discussion is free to email me
directly so we can organize.

Tom.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3572.html

[Nevin Liber]

Post by Nicol Bolas
Consider Herb Sutter's idea for a standardized "Lightweight Drawing
Library". He issued an outline of what he wanted. The problem is that,
well, he doesn't know much about this sort of thing. However, he didn't
follow the standard committee process of, "Gee, I hope that someone comes
along and writes a proposal.

People on mailing lists may sit around hoping that someone comes along and
writes a proposal, but people on the committee don't. When we are
enthusiastic about something and want to see a change, we get directly
involved and help make it happen.

Because Herb is passionate about the subject, he got a paper written and
people to champion it.

Post by Nicol Bolas
And attends meetings. And gets feedback and writes new versions of the
proposal. For years. Until hopefully it makes it through."

Those people attended meetings. They got feedback. They wrote new
versions of the proposal; N3888
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf>, N4021
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf>, N4073
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4073.pdf> are all
revisions of the same paper. They were written in 2014, so we are now on
year #2. Hopefully it will make it through.

Exactly how did he not follow the standard committee process?

In his capacity as a member of the C++ standards committee (and a major

Post by Nicol Bolas
person in the C++ scene), he actually sought out experts in this domain. He
went out and found people to write a proposal. He used his influence to cut
through the general red tape that surrounds committee proposals and ensure
that this would actually happen.

What red tape is that?

The minimal bar is that someone has to write a paper and someone has to
champion that paper at a meeting. *You do not have to be a committee
member to do either of those things.*

Post by Nicol Bolas
The members of the standards committee should be doing more than just
reacting to proposals. They need to be actively trying to develop specific
features that improve C++ in various ways. They should be looking at where
C++ is deficient and working to resolve those deficiencies.

It is an all-volunteer organization. Members can do what they want. That
being said, many (if not most) members do write and/or champion proposals
and/or help others. I don't see how to get any more proactive than that.

Post by Nicol Bolas
The committee should have initiatives like Herb's, drives to push towards
some specific end. The committee's current process only reacts to
proposals; it doesn't proactively seek out solutions to specific C++
problems. What Herb did is the exception rather than the rule.

It never ceases to amaze me how people who don't volunteer to come and help
the committee (or any volunteer organization, for that matter) do its work
want to boss around those that do.

If you think this needs doing and isn't being done, *why aren't you doing
it?*

Ville specifically said "We are more than eager to welcome hard-working
individuals who are willing to write and champion proposals and implement
prototypes." So, are you going to do it? If not, while I wouldn't say
that you are necessarily lazy, it does indicate that standardization isn't
important to you compared with other things in your life. It is your
choice whether you want to be a vocal but passive follower or an active
contributor.

Post by Nicol Bolas
I consider this passive approach to be lazy: it puts all of the work is on
the *proposer*, not the committee. Even the desire for the feature is on
the proposer, not the committee (even if the proposer happens to be on the
committee). If the proposer doesn't show up after the commentary on the
proposer, then it just doesn't get done.

That is life in an all-volunteer organization.

Post by Nicol Bolas
Unicode in C++ is an important problem. It is of sufficient importance
that the committee *itself* should have shown the initiative to make sure
that it gets solved. If one person didn't want to continue the proposal,
another interested expert should have been *sought out*, rather than them
simply waiting and hoping such a person would appear. The committee should
have been proactive in providing whatever support was needed to keep the
proposal moving and progressing. And if it wasn't progressing fast enough
or if the original person wanted to stop, the committee should have gone
out to find someone else to do it.

*I invoke my magical powers as a Committee Member to volunteer you to do my
bidding for no compensation.*

I expect to see you, your proposal and sample implementation for Unicode in
Lenexa.
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[Tom Honermann]

Post by Nicol Bolas
My favorite example of this is the proposal for Unicode library support in
C++. It was pretty comprehensive, ranging from specialized iterators to
string types, with Unicode normalization, and lots of other features. It
effectively died on the vine. There was a proposal, it was reviewed (IIRC,
the proposer wasn't able to attend, and had some trouble getting accurate
feedback about what happened), and... that was it. Eventually, despite
clearly having both an interest in the feature and some knowledge on the
subject, he just seemed to give it up as a bad job.

I presume you are referring to N3572 [1]. My understanding is that the
committee rejected the approach of providing an additional string class. I
think this was the right decision. I don't think there have been any
further proposals since then.

I'm interested in improving Unicode support and have been working on
something for which I plan to submit a proposal Real Soon Now (pending
time/energy). It will just be a small step though, nothing comprehensive,
but it does avoid the yet-another-string-class approach. It is essentially
a view/range/iterator approach to enumerating code points in arbitrary
encodings. I hope to have it ready for Lenexa. Regardless of whether I'm
able to submit it for discussion there or not, I would be interested in
meeting with any interested parties to discuss improving Unicode support in
Lenexa. Anyone interested in such a discussion is free to email me
directly so we can organize.

Tom.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3572.html

[Tony V E]

<snip C++ committee blah blah blah>

If anyone wants to pay me to spend more time on C++ committee matters, I
will open a kickstarter. As a stretch goal, I will throw in developing
libraries for Boost.
I am constantly surprised that my current employer lets me spend as much
time (and money) as they already do, but if someone wants to donate, I can
arrange to spend more. It would be a great full time job if only someone
would pay for it.

Currently I don't have time to read the 100 proposals for the next meeting,
let alone write my own, let alone write something someone else wants.
Which is more important - reading, understanding, improving, voting, etc
existing proposals, or ignoring them and writing my own?

I also don't have clones of me to be in all the subcommittee rooms at the
same time. :-(

To me, the standard is actually moving too fast. At least too fast for me.
I worry about some of the long term repercussions of our decisions.

Tony

[g***@gmail.com]

Post by Tony V E
<snip C++ committee blah blah blah>
If anyone wants to pay me to spend more time on C++ committee matters, I
will open a kickstarter. As a stretch goal, I will throw in developing
libraries for Boost.
I am constantly surprised that my current employer lets me spend as much
time (and money) as they already do, but if someone wants to donate, I can
arrange to spend more. It would be a great full time job if only someone
would pay for it.

I actually think this is an awesome idea and you did this. I have thought
about this before a little - not for me but for Committee regulars with the
desire and experience.

I think the plan should be something like this:

* Round up fellow interested people who can commit to this concept if
funding was present.
- not a one and band thing.
* Solicit donation from ioscpp to fund website changes to isocpp to allow
better public participation. - e.g. to be able to vote for features and
suggested design directions etc.
* Draw up a list of kickstarter goals. Things like:
* propose language changes for delivery speed up: Uniform Function Call
Syntax, Overloading Operator Dot, Concepts, Modules, and Open Pattern
Matching and Multi Methods proposals.
* determine desirable library features X, Y, Z
* draw up agenda, plan and feature list
* solicit overall thoughts on this site
* vote on all of the above on this site.
* do kickstarter complain to implement the voted upon agenda/plan with
delivery goals dates, stretches etc.
* manage direction / progress / plan changes on this site via voting etc.
* implement in clang and gcc.etc.
* Enjoy some payment for your efforts.

Post by Tony V E
Currently I don't have time to read the 100 proposals for the next
meeting, let alone write my own, let alone write something someone else
wants.
Which is more important - reading, understanding, improving, voting, etc
existing proposals, or ignoring them and writing my own?
I also don't have clones of me to be in all the subcommittee rooms at the
same time. :-(
To me, the standard is actually moving too fast. At least too fast for
me. I worry about some of the long term repercussions of our decisions.

Anything particular you want to call out?

Post by Tony V E
Tony

Please do this. Thanks! :)

[Ville Voutilainen]

Post by g***@gmail.com
* Round up fellow interested people who can commit to this concept if
funding was present.
- not a one and band thing.
* Solicit donation from ioscpp to fund website changes to isocpp to allow
better public participation. - e.g. to be able to vote for features and
suggested design directions etc.
* propose language changes for delivery speed up: Uniform Function Call
Syntax, Overloading Operator Dot, Concepts, Modules, and Open Pattern
Matching and Multi Methods proposals.
* determine desirable library features X, Y, Z
* draw up agenda, plan and feature list
* solicit overall thoughts on this site
* vote on all of the above on this site.
* do kickstarter complain to implement the voted upon agenda/plan with
delivery goals dates, stretches etc.
* manage direction / progress / plan changes on this site via voting etc.
* implement in clang and gcc.etc.
* Enjoy some payment for your efforts.

Well, I suppose in general it's a good idea to get feedback from programmers.
A couple of questions, though:

1) What's the value of "proposing features for delivery speed-up", if there's no
additional work done on it? It's easy to say "I really want this", the
hard part is
helping proposals to be good enough to be adopted. That's _not_ a question
of "red tape" - it's a question of proposal quality.

2) It's already possible to sponsor people doing implementation work -
but, then again,
having a bounty system on some website for such things wouldn't be a
bad idea in and
of itself - but having said that, isocpp.org is perhaps a wrong place
for it, unless you
think open and closed implementations can be treated equivocally in
such a system.

3) Regarding voting on whatever matter, how do you prevent idiots from
voting? That's
a serious question. Rigid as our procedures may be, the committee
doesn't have a single
idiot as a member. A completely open system that is supposed to have
an effect on
the work of the committee runs into the risk of being biased towards
the preference
of idiots.

Another anecdote, regarding the alleged importance of unicode that was
mentioned:
it doesn't matter how many votes you gather, and it doesn't matter how
much money
you gather, but for me personally (remember, this is an anecdote),
unicode support
remains far far far at the bottom of the list of things I will work on
to standardize. I can
easily find three dozen things I'll donate my off-day-work hours before that.

I'm not against something like what you depict - but the question is
how useful will it
be, and what beneficial effect would something like that supposedly have?

Having people outside the committee participate in the standards work
is a great idea.
The problematic part is having them participate in useful ways.

[Tony V E]

Post by g***@gmail.com

Post by Tony V E
<snip C++ committee blah blah blah>
If anyone wants to pay me to spend more time on C++ committee matters, I
will open a kickstarter. As a stretch goal, I will throw in developing
libraries for Boost.
I am constantly surprised that my current employer lets me spend as much
time (and money) as they already do, but if someone wants to donate, I can
arrange to spend more. It would be a great full time job if only someone
would pay for it.

I actually think this is an awesome idea and you did this. I have thought
about this before a little - not for me but for Committee regulars with the
desire and experience.
* Round up fellow interested people who can commit to this concept if
funding was present.
- not a one and band thing.
* Solicit donation from ioscpp to fund website changes to isocpp to allow
better public participation. - e.g. to be able to vote for features and
suggested design directions etc.
* propose language changes for delivery speed up: Uniform Function Call
Syntax, Overloading Operator Dot, Concepts, Modules, and Open Pattern
Matching and Multi Methods proposals.
* determine desirable library features X, Y, Z
* draw up agenda, plan and feature list
* solicit overall thoughts on this site
* vote on all of the above on this site.
* do kickstarter complain to implement the voted upon agenda/plan with
delivery goals dates, stretches etc.
* manage direction / progress / plan changes on this site via voting etc.
* implement in clang and gcc.etc.
* Enjoy some payment for your efforts.

Post by Tony V E
Currently I don't have time to read the 100 proposals for the next
meeting, let alone write my own, let alone write something someone else
wants.
Which is more important - reading, understanding, improving, voting, etc
existing proposals, or ignoring them and writing my own?
I also don't have clones of me to be in all the subcommittee rooms at the
same time. :-(
To me, the standard is actually moving too fast. At least too fast for
me. I worry about some of the long term repercussions of our decisions.

Anything particular you want to call out?

Post by Tony V E
Tony

Please do this. Thanks! :)
--

Not sure it would work. It was more of a joke. I do think it highlights a
real issue: time (== money) to participate.

For me there is definitely one "technical" problem. I am a member of the
Standards Council of Canada. I can't take "bribes" as to what features to
vote on. So you could probably pay me to do *directed* work on something
like Boost libraries, _maybe_ even directed work on Standards proposals,
but you can't expect me to actually vote for proposals that I don't agree
with, just because you funded it.

You might be able to pay me to do *undirected* work on the Standard - ie
have complete faith that I whatever I decide is best really is best for you
(and Canada!). For some reason my employer (and country) currently have
that opinion. That sounds scary to me, now that I wrote it! (It is also
why most of my standards work is on my own time.)


Regardless of my situation, you could have a similar problem in the
kickstarter in general - do you work on whatever the highest payer asked
you to work on? Do you vote on direction based on $? Or do you set the
direction first, then see who wants to fund it? Need to be careful there.

Tony

[Ville Voutilainen]

Post by Tony V E
For me there is definitely one "technical" problem. I am a member of the
Standards Council of Canada. I can't take "bribes" as to what features to
vote on. So you could probably pay me to do *directed* work on something
like Boost libraries, _maybe_ even directed work on Standards proposals, but
you can't expect me to actually vote for proposals that I don't agree with,
just because you funded it.

That situation is not entirely unique as far as national
representatives are concerned.
I don't know whether there are any rules related to that, but in my
case the point is
moot. Bribing me costs a billion dollars, any sum less than that won't
do. (Everybody's
got a price, right? ;) ) Reasonable sponsorship of my work as *I* see
fit is a completely
different matter.

Post by Tony V E
You might be able to pay me to do *undirected* work on the Standard - ie
have complete faith that I whatever I decide is best really is best for you
(and Canada!). For some reason my employer (and country) currently have
that opinion. That sounds scary to me, now that I wrote it! (It is also
why most of my standards work is on my own time.)

Having people sponsored by their employers is not really that different
from having people sponsored by a kickstarter community. So in that sense,
I don't think sponsoring committee experts via a community effort is
impossible. It's up to every individual NB-designated expert whether they
can accept such funding or not. In my case, it would complicate tax matters. ;)

Post by Tony V E
Regardless of my situation, you could have a similar problem in the
kickstarter in general - do you work on whatever the highest payer asked you
to work on? Do you vote on direction based on $? Or do you set the
direction first, then see who wants to fund it? Need to be careful there.

I think it's rational and reasonable not to expect any proposal author/champion
to be purely guided by the opinions of his/her sponsors. We have ample
examples of technical experts who have no trouble solving the disagreement
between the desires of their sponsors/employers and their own judgement.
In that sense, throwing money at a desire to advance a given proposal may
or may not work.

[Cleiton Santoia]

Post by a***@gmail.com
What are your plans to make C++ clean and easier to learn/use?

Your statement above may implies that if committee does not agree with you,
then they are not committed to make c++ easier and better, some one may
understand that as "rude" don't you think ? Even if it's not you intention.

The point is: did you like the solution I gave ? Do you will use it ? Tell
us if it worked ...


Cleiton

[a***@gmail.com]

And even if it was so (but it's not), how would make me that not to
"deserve"?
No, I'm not being rude. If one doesn't agree with somebody it does not make
him immediately rude. Everyone is entitled to their opinions.
You on the other hand were rude towards me. That's why I've pointed that
out to you.

Post by Cleiton Santoia

Post by a***@gmail.com
What are your plans to make C++ clean and easier to learn/use?

Your statement above may implies that if committee does not agree with
you, then they are not committed to make c++ easier and better, some one
may understand that as "rude" don't you think ? Even if it's not you
intention.
The point is: did you like the solution I gave ? Do you will use it ? Tell
us if it worked ...
Cleiton

[Cleiton Santoia]

No, I'm not being rude. If one doesn't agree with somebody it does not make
him immediately rude. Everyone is entitled to their opinions. ;-)


And my "entitled opinion" on "deserve" part is easy to understand :

I spent more effort implementing the solution of the problem then you (
actually I liked to do it ).
Do you will uses it with grate care and joy or you will be rude with me and
let it die into oblivion ? Does my great effort is important to you or
worthless ?
Apparently you want to all C++ community use it, but how much effort you
will put on this ?


Anyway I like your posts, I like how the discussion got hot and passionate,
so I wonder: can you use this force for the good ?



Cleiton

Post by a***@gmail.com
And even if it was so (but it's not), how would make me that not to
"deserve"?
No, I'm not being rude. If one doesn't agree with somebody it does not
make him immediately rude. Everyone is entitled to their opinions.
You on the other hand were rude towards me. That's why I've pointed that
out to you.

Post by Cleiton Santoia

Post by a***@gmail.com
What are your plans to make C++ clean and easier to learn/use?

Your statement above may implies that if committee does not agree with
you, then they are not committed to make c++ easier and better, some one
may understand that as "rude" don't you think ? Even if it's not you
intention.
The point is: did you like the solution I gave ? Do you will use it ?
Tell us if it worked ...
Cleiton

[a***@gmail.com]

As for the solution you gave:
I didn't have time to try it but I'm pretty certain that it will work as
intended. The point is that it is not a standard solution and you can't
expect people to using it globally.

Post by Cleiton Santoia

Post by a***@gmail.com
What are your plans to make C++ clean and easier to learn/use?

Your statement above may implies that if committee does not agree with
you, then they are not committed to make c++ easier and better, some one
may understand that as "rude" don't you think ? Even if it's not you
intention.
The point is: did you like the solution I gave ? Do you will use it ? Tell
us if it worked ...
Cleiton

[David Krauss]

I didn't have time to try it but I'm pretty certain that it will work as intended. The point is that it is not a standard solution and you can't expect people to using it globally.

The point is that it only took him 10 minutes to write it, so although you can’t expect everyone to do the exact same thing verbatim, any competent person who’s seriously having this problem can reach the same conclusion.

It’s a very simple template. I’m pretty sure it’s appeared before on this forum in previous discussions. Also, it wouldn’t be surprising if Boost had one. Standardizing it would be way easier than changing or extending the core semantics of initialization. (Of course, it doesn’t help folks who didn’t use typedefs.)

[Ville Voutilainen]

Post by David Krauss

I didn't have time to try it but I'm pretty certain that it will work as intended. The point is that it is not a standard solution and you can't expect people to using it globally.

The point is that it only took him 10 minutes to write it, so although you can’t expect everyone to do the exact same thing verbatim, any competent person who’s seriously having this problem can reach the same conclusion.
It’s a very simple template. I’m pretty sure it’s appeared before on this forum in previous discussions. Also, it wouldn’t be surprising if Boost had one. Standardizing it would be way easier than changing or extending the core semantics of initialization. (Of course, it doesn’t help folks who didn’t use typedefs.)

Yes - this is a library solution to the original problem. Based on the
compatibility problems
of a language change, perhaps it would be better to pursue that
library solution, and work
on standardizing that instead. Even so, I doubt the motivation for
such a type is strong
enough, if it doesn't do anything else besides value-init-on-default-init.

[David Krauss]

Post by Ville Voutilainen
Even so, I doubt the motivation for
such a type is strong
enough, if it doesn't do anything else besides value-init-on-default-init.

Well, it’s also a numeric wrapper via conversion functions, of which it has three. Settling on best practices for that is an orthogonal issue, though. It would be nice to see more papers addressing interface wrapping, and it would be a bit painful to see such an interface get standardized when it might soon become dated.

[a***@gmail.com]

I'm not sure I get your point but if you don't want to have this
initialized you would explicitly state that:
int large[1000000000] = delete;

and nothing would change except that your intentions would be clear and
obvious stated in code.

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not
be left uninitialized? That would I believe solved all those problems?

Should it be a compile time error (thus breaking old C code), or should
C++ be required to always initialize all variables (thus making old C
code run slower as C++)?
How fast is this program running?
int large[1000000000];
int main()
{ }
Bo Persson

Post by a***@gmail.com

Post by a***@gmail.com
No, I'm not suggesting that.

What, then? The program is supposed to skip a constructor that the
user explicitly
stated can not be skipped?

[a***@gmail.com]

To answer your question, I believe it should be compile time error.
Breaking old C code. I'm afraid in order to clean sometimes you have to
make dust first. It is impossible to clean C++ without breaking old code.
But I believe that with that rule, the old code would get cleaned up and be
safer and correct.

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not
be left uninitialized? That would I believe solved all those problems?

Should it be a compile time error (thus breaking old C code), or should
C++ be required to always initialize all variables (thus making old C
code run slower as C++)?
How fast is this program running?
int large[1000000000];
int main()
{ }
Bo Persson

Post by a***@gmail.com

Post by a***@gmail.com
No, I'm not suggesting that.

What, then? The program is supposed to skip a constructor that the
user explicitly
stated can not be skipped?

[Nicol Bolas]

Post by a***@gmail.com
To answer your question, I believe it should be compile time error.
Breaking old C code. I'm afraid in order to clean sometimes you have to
make dust first. It is impossible to clean C++ without breaking old code.

Then we won't have clean C++.

You value your notion of "cleanliness". We get that. What you need to
understand is that the rest of us, and *especially* the standards
committee, values not breaking people *far more* than mere "cleanliness".

Breaking working code is a non-starter. Please stop suggesting things that
are non-starters; it just wastes everyone's time.

Also, please stop posting these things on "ISO C++ Standard - Discussion"
This forum/ML/GoogleGroup/etc is for talking about the standard *as it is
now*, not for talking about how you want the standard to be.

[Thiago Macieira]

Post by Nicol Bolas
Also, please stop posting these things on "ISO C++ Standard - Discussion"
This forum/ML/GoogleGroup/etc is for talking about the standard *as it is
now*, not for talking about how you want the standard to be.

That's what the std-proposals group is for. But you need to write a proposal
of how you're going to accomplish your objective.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Thiago Macieira]

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not
be left uninitialized? That would I believe solved all those problems?

Should it be a compile time error (thus breaking old C code), or should
C++ be required to always initialize all variables (thus making old C
code run slower as C++)?
How fast is this program running?
int large[1000000000];
int main()
{ }

That's a bad example since the "large" variable is zero-initialised. Globals
are always initialised.

You wanted to write:

int main()
{
int large[10000000];
someFunction(large);
}

Automatic storage variables can be left uninitialised. And in this case, it
may be the correct thing to do: we don't know what someFunction will do to
"large".

In fact, quite a few declarations of char arrays inside function bodies are
buffers locally used and seldomly do they need to be filled in before use...
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Sarfaraz Nawaz]

@Bo Persson,

Since the variable `large` has the static storage duration, it'll be (zero)
initialized anyway, even in the current Standard. So maybe you meant this:

int main() { int large[1000000000]; .... }

Post by a***@gmail.com
Yes I see your point. What about rule that all built in types must not
be left uninitialized? That would I believe solved all those problems?

Should it be a compile time error (thus breaking old C code), or should
C++ be required to always initialize all variables (thus making old C code
run slower as C++)?
How fast is this program running?
int large[1000000000];
int main()
{ }
Bo Persson

Post by a***@gmail.com

Post by a***@gmail.com
No, I'm not suggesting that.

What, then? The program is supposed to skip a constructor that the
user explicitly
stated can not be skipped?

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

[Nevin Liber]

Post by a***@gmail.com
Guys, I'm not sure if we agree on that but I think that uninitialized
variables in most cases are bad. There are few scenarios that there is
desirable not to have variable initialized like for example large buffer
which we will be reading to in next line, but apart from those few
examples, having uninitialized variables isn't something that I would like
to come across.
char a[100];
would be treated as an error. In order for having this uninitialized user
char a[100] = delete;
Looking forward to hear your opinions

Didn't *you* bring up this exact issue back in 2012 on std-proposals? What
has changed since then for you to bring it up again?
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[a***@gmail.com]

It may've been me. I've had a long break from C++.

Post by Nevin Liber

Post by a***@gmail.com
Guys, I'm not sure if we agree on that but I think that uninitialized
variables in most cases are bad. There are few scenarios that there is
desirable not to have variable initialized like for example large buffer
which we will be reading to in next line, but apart from those few
examples, having uninitialized variables isn't something that I would like
to come across.
char a[100];
would be treated as an error. In order for having this uninitialized user
char a[100] = delete;
Looking forward to hear your opinions

Didn't *you* bring up this exact issue back in 2012 on std-proposals?
What has changed since then for you to bring it up again?
--
691-1404

[Nevin Liber]

Post by a***@gmail.com
It may've been me. I've had a long break from C++.

If you can't bother to go look (both std::proposals and Gmail archives
everything), why should we bother to comment?

In case you still cannot find the discussion on this that you started back
in 2012:
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/CuxYuf7fSUc/YrRMJzrXrO8J

Please address all the points brought up in that thread before going
further.
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[a***@gmail.com]

Hi, thanks for that link:
Will try to address each one of them separately:
1) Andrzej Krzeminski

I believe it would be an unacceptable performance penalty in cases where
the value is intended to be populated in the next line:

T var;
std::cin >> var;

This can be easily corrected (and make the intentions of a programmer
clear) by saying:
T var = delete;
std::cin >> var;

Post by Nevin Liber

Post by a***@gmail.com
It may've been me. I've had a long break from C++.

If you can't bother to go look (both std::proposals and Gmail archives
everything), why should we bother to comment?
In case you still cannot find the discussion on this that you started back
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/CuxYuf7fSUc/YrRMJzrXrO8J
Please address all the points brought up in that thread before going
further.
--
691-1404

[Casey Carter]

Post by Nevin Liber
In case you still cannot find the discussion on this that you started back
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/CuxYuf7fSUc/YrRMJzrXrO8J
Please address all the points brought up in that thread before going
further.
--
691-1404

There's plenty of discussion in
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/intialized/std-proposals/eD78u8jDaCA/TprA-kjcAfwJ
from 2014 as well.

[Johannes Schaub]

Post by a***@gmail.com
Guys, I'm not sure if we agree on that but I think that uninitialized
variables in most cases are bad. There are few scenarios that there is
desirable not to have variable initialized like for example large buffer
which we will be reading to in next line, but apart from those few examples,
having uninitialized variables isn't something that I would like to come
across.
char a[100];
would be treated as an error. In order for having this uninitialized user
char a[100] = delete;
Looking forward to hear your opinions

It's easy to avoid breaking code. I would propose that whether or not
"char a[100];" is valid is implementation-defined. "= delete" could be
used and it must be accepted by all implementations.

[Ville Voutilainen]

On 21 March 2015 at 19:02, Johannes Schaub

Post by Johannes Schaub
It's easy to avoid breaking code. I would propose that whether or not
"char a[100];" is valid is implementation-defined.

How does that avoid breaking code?

[Johannes Schaub]

Post by Ville Voutilainen
On 21 March 2015 at 19:02, Johannes Schaub

Post by Johannes Schaub
It's easy to avoid breaking code. I would propose that whether or not
"char a[100];" is valid is implementation-defined.

How does that avoid breaking code?

In the same way that having "int a = ((1 + 2) * 3 + 4) * 5;" valid or
not is implementation defined (exceeding the number of "Nesting levels
of parenthesized expressions").

[Ville Voutilainen]

On 21 March 2015 at 19:13, Johannes Schaub

Post by Johannes Schaub

Post by Ville Voutilainen

Post by Johannes Schaub
It's easy to avoid breaking code. I would propose that whether or not
"char a[100];" is valid is implementation-defined.

How does that avoid breaking code?

In the same way that having "int a = ((1 + 2) * 3 + 4) * 5;" valid or
not is implementation defined (exceeding the number of "Nesting levels
of parenthesized expressions").

In other words, not at all. So no thanks. You can freely convince an
implementation
vendor to add a diagnostic for uninitialized variables.

[Johannes Schaub]

Post by Ville Voutilainen
On 21 March 2015 at 19:13, Johannes Schaub

Post by Johannes Schaub

Post by Ville Voutilainen

Post by Johannes Schaub
It's easy to avoid breaking code. I would propose that whether or not
"char a[100];" is valid is implementation-defined.

How does that avoid breaking code?

In the same way that having "int a = ((1 + 2) * 3 + 4) * 5;" valid or
not is implementation defined (exceeding the number of "Nesting levels
of parenthesized expressions").

In other words, not at all. So no thanks. You can freely convince an
implementation
vendor to add a diagnostic for uninitialized variables.

GCC for example already was convinced to reject a substantial portion
of the worlds' C++ code in some of their implementation modes
("-Werror"). Similar we can add a "-Wuninitialized-pedantic" to warn
for "int a; a = 0;" and require use of "int a = delete;" to avoid the
warning.

[Ville Voutilainen]

On 21 March 2015 at 19:24, Johannes Schaub

Post by Johannes Schaub
GCC for example already was convinced to reject a substantial portion
of the worlds' C++ code in some of their implementation modes
("-Werror"). Similar we can add a "-Wuninitialized-pedantic" to warn
for "int a; a = 0;" and require use of "int a = delete;" to avoid the
warning.

Sure you can. That has nothing to do with the standard. We are not going to make
uninitialized variables either ill-formed or implementation-specific.

[Johannes Schaub]

Post by Ville Voutilainen
On 21 March 2015 at 19:24, Johannes Schaub

Post by Johannes Schaub
GCC for example already was convinced to reject a substantial portion
of the worlds' C++ code in some of their implementation modes
("-Werror"). Similar we can add a "-Wuninitialized-pedantic" to warn
for "int a; a = 0;" and require use of "int a = delete;" to avoid the
warning.

Sure you can. That has nothing to do with the standard. We are not going to make
uninitialized variables either ill-formed or implementation-specific.

Thanks. For the record, I don't like having variables ill-formed or
implementation-specific either. The current rules seem to suffice.

[Tony V E]

On Sat, Mar 21, 2015 at 1:38 PM, Ville Voutilainen <

Post by Ville Voutilainen
On 21 March 2015 at 19:24, Johannes Schaub

Post by Johannes Schaub
GCC for example already was convinced to reject a substantial portion
of the worlds' C++ code in some of their implementation modes
("-Werror"). Similar we can add a "-Wuninitialized-pedantic" to warn
for "int a; a = 0;" and require use of "int a = delete;" to avoid the
warning.

Sure you can. That has nothing to do with the standard. We are not going to make
uninitialized variables either ill-formed or implementation-specific.
--

How about making uninitialized variables value-initialized *8 years after*
introducing "int a = delete" ?
Then it is only a performance-breakage, with lots of time to correct for it.

Tony

[Nevin Liber]

Post by Tony V E
How about making uninitialized variables value-initialized *8 years after*
introducing "int a = delete" ?
Then it is only a performance-breakage, with lots of time to correct for it.

Because recompiling your C or C++ code with a new compiler to make it
slower is a such a good selling point -- NOT.

I fail to see how this addresses the issue which people keep bringing up
where we can use tools nowadays to catch access to uninitialized variables,
but once that code becomes legal, it is impossible to use those tools,
because accessing wrongly initialized variables is indistinguishable from
accessing correctly initialized variables.

At this point, I don't see any new information being discussed over any of
the previous discussions. You should either write a proposal (so we can
bring up these same points in EWG once and for all) or drop it.
--
Nevin ":-)" Liber <mailto:***@eviloverlord.com> [phone]

[Tony V E]

Post by Nevin Liber

Post by Tony V E
How about making uninitialized variables value-initialized *8 years
after* introducing "int a = delete" ?
Then it is only a performance-breakage, with lots of time to correct for it.

Because recompiling your C or C++ code with a new compiler to make it
slower is a such a good selling point -- NOT.

I assume that you would have a few years of a compiler warning you about it
before the "deprecation" was turned on.

Post by Nevin Liber
I fail to see how this addresses the issue which people keep bringing up
where we can use tools nowadays to catch access to uninitialized variables,
but once that code becomes legal, it is impossible to use those tools,
because accessing wrongly initialized variables is indistinguishable from
accessing correctly initialized variables.

I think there is merit in keeping it UB. However, in my experience,
uninitialized variables are hard to find bugs (when a tool doesn't find it
for you) because what happens is that the code works fine for 6 months and
then one week before shipping something "unrelated" changes and makes the
uninitialized variable become 17 instead of 0. And then you are scrambling
to find the bug.

If the variables were always value-initialized, maybe you have a bug, but
at least you likely have a consistent, reproducible bug.

Post by Nevin Liber
At this point, I don't see any new information being discussed over any of
the previous discussions. You should either write a proposal (so we can
bring up these same points in EWG once and for all) or drop it.

I do think there is some merit in the proposal - I doubt any new language
today would make uninitialized the default; but it is not a priority for
me. I can write emails about it, but not a proposal.

Tony

[Christopher Jefferson]

Post by Tony V E
On Sat, Mar 21, 2015 at 1:38 PM, Ville Voutilainen

Post by Ville Voutilainen
On 21 March 2015 at 19:24, Johannes Schaub

Post by Johannes Schaub
GCC for example already was convinced to reject a substantial portion
of the worlds' C++ code in some of their implementation modes
("-Werror"). Similar we can add a "-Wuninitialized-pedantic" to warn
for "int a; a = 0;" and require use of "int a = delete;" to avoid the
warning.

Sure you can. That has nothing to do with the standard. We are not going to make
uninitialized variables either ill-formed or implementation-specific.
--

How about making uninitialized variables value-initialized *8 years after*
introducing "int a = delete" ?
Then it is only a performance-breakage, with lots of time to correct for it.

Because it is still going to be a *HUGE* amount of work.

My advice to anyone wanting to do this is, at the least:

1) Implement this in gcc or clang.
2) Get some big software projects (gcc, clang, firefox, chrome, boost
for example) recompiling with this change, and see how much work it
is.
3) See what performance regressions there are.

These kind of hard numbers are the only way to convince people (like
myself) that this change isn't going to create an unacceptably huge
amount of work.

There is past experience of this -- at one point we hoped to make NULL
be nullptr, until Microsoft added that to VC++10 and found that is
broke unacceptably huge amount of code.

Chris

[Ville Voutilainen]

Post by Christopher Jefferson

Post by Tony V E
How about making uninitialized variables value-initialized *8 years after*
introducing "int a = delete" ?
Then it is only a performance-breakage, with lots of time to correct for it.

Because it is still going to be a *HUGE* amount of work.
1) Implement this in gcc or clang.
2) Get some big software projects (gcc, clang, firefox, chrome, boost
for example) recompiling with this change, and see how much work it
is.
3) See what performance regressions there are.
These kind of hard numbers are the only way to convince people (like
myself) that this change isn't going to create an unacceptably huge
amount of work.
There is past experience of this -- at one point we hoped to make NULL
be nullptr, until Microsoft added that to VC++10 and found that is
broke unacceptably huge amount of code.

Even with such an experiment, requiring =delete is incompatible with C.
I was mildly supportive of the idea until I realized that it would create that
additional incompatibility.

[David Krauss]

Post by Ville Voutilainen
Even with such an experiment, requiring =delete is incompatible with C.
I was mildly supportive of the idea until I realized that it would create that
additional incompatibility.

To merely compile C++ code containing =delete, without any changes to C, simply include the equals sign in a compatibility macro.

#if __cplusplus
#define uninitialized =delete
#else
#define uninitialized /*no initializer*/
#endif

By the way, what’s wrong with the [[uninitialized]] attribute mentioned by David Rodríguez? Attributes fit perfectly here: it’s only a means of disabling a potential extension or adjusting diagnostics. And even if default zero-initialization were one day standardized, the attribute would still not be a problem because, for a well-behaved program, the value must be unused.

For C compatibility, the attribute also avoids sucking the equals sign into the macro.

[Ville Voutilainen]

Post by David Krauss
To merely compile C++ code containing =delete, without any changes to C,
simply include the equals sign in a compatibility macro.
#if __cplusplus
#define uninitialized =delete
#else
#define uninitialized /*no initializer*/
#endif

And make sure that that macro is used in every translation unit that needs
it. That requires changes to all code that needs the macro, which breaks
existing code just as much as the proposed change does in its bare form.

Post by David Krauss
By the way, what’s wrong with the [[uninitialized]] attribute mentioned by
David Rodríguez? Attributes fit perfectly here: it’s only a means of

An attribute that has a semantic effect? That's not what attributes are for,
so I don't quite see how it "fits perfectly".

After all this discussion, I haven't seen a single reason not to object to this
idea.

[Daniel Krügler]

Post by Ville Voutilainen

By the way, what's wrong with the [[uninitialized]] attribute mentioned by
David Rodríguez? Attributes fit perfectly here: it's only a means of

An attribute that has a semantic effect? That's not what attributes are for,
so I don't quite see how it "fits perfectly".

There was a leeway for such a use-case expressed in the section
"Guidance on when to use/reuse a keyword and when to use an attribute
" of

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2553.pdf

Among them "that does not alter its semantics significantly". One
could argue that the proposed [[noexit]] attribute is similarly
affected by semantic "burden":

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4357.html

Nonetheless one of the exclusion criteria was

"The feature is a central part of the declaration that significantly
affects its requirements/semantics (e.g., constexpr). "

This rule can presumably be considered as counter-argument for this
case. To me the overall situation is not really clear and I could live
with allowing that.

- Daniel

[David Krauss]

Post by Ville Voutilainen
An attribute that has a semantic effect? That's not what attributes are for,
so I don't quite see how it "fits perfectly”.

There’s no semantic effect. Without the attribute, the variable is uninitialized. With the attribute, the variable is uninitialized. It just states what already happens.

Given the attribute, the implementation can decide to suppress an extension like David mentioned, or -Wuninitialized since the intent was positively confirmed. Warning suppression would help portability under -Werror -Wuninitialized, since static analysis unpredictable across platforms.

If [[uninitialized]] is applied to something that already gets zero-initialization, the implementation can provide a warning about inappropriate attribute usage. I think it would be OK to go further and suppress zero-initialization, potentially changing the behavior of the program, as long as the attribute requires that the uninitialized value not be used. As with [[noreturn]], UB is OK inside cases that the attribute declares won’t happen. However, even if that opinion is wrong, the attribute is still valid and valuable.