WG14 Post Santa Clara mailing available

[=?iso-8859-1?q?Keld_J=F8rn?= Simonsen]

The Post Santa Clara mailing is now available from the WG14 web site at
http://www.open-std.org/jtc1/sc22/wg14

I also updated some of the other information on the pages.

Best regards
Keld Simonsen

[Keith Thompson]

Paul Hsieh <we******@gmail .comwrites:

On Oct 18, 6:30*am, James Kuyper <jameskuy...@ve rizon.netwrote:

[...]

>If they're going to include such a change in a future version of the C
standard, then the first step should be to deprecate the current usage
of "auto", which is precisely what the committee has decided to do.

I don't follow the logic. Will C++ specifically require the
deprecation of the old use of auto to support its new usage? Or is
this just introducing a difference for no reason?

The following is largely speculation on my part.

C++ is adding a new meaning for the "auto" keyword. At the same time,
C++ is dropping the old meaning. These two things are not
*necessarily* connected (C++ could have kept the old meaning), but (a)
use of "auto" with the old meaning is vanishingly rare in both C and
C++, and (b) having two meanings for the same keyword, though it's not
a problem for compilers, would make the language just a little bit
more confusing than it needs to be. (Compare "static".)

The reasons for making either change in C++ aren't quite as strong.
Dropping, or rather deprecating, the old meaning makes some sense, but
the reasons for doing so arguably aren't strong enough by themselves
to justify a language change. Avoiding gratuitous incompatibility
with C++ makes the justification just a little bit stronger. And if,
some day, C adopts C++'s new meaning for auto, having deprecated the
old one makes the resulting new C just a little bit less confusing.

As far as I know, any legal C program that uses the auto keyword would
be unaffected by simply deleting all occurrences. In other words, if
a C compiler had a predefined macro definition equivalent to

#define auto /* nothing */

then it wouldn't break anything. (This wasn't the case for pre-ANSI
C, where "auto x;" at block scope was a legal declaration; I'm not
sure whether it's true in C90.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kuyper]

Paul Hsieh wrote:

On Oct 18, 6:30 am, James Kuyper <jameskuy...@ve rizon.netwrote:

....

>It is commonplace in C++ code to not be sure what the type of an
expression is. The biggest reason for this is templates; but the
overloading of functions is also a contributing factor. This makes the
new C++ meaning attached to "auto" very convenient.

As I understand it, this isn't a lack of being sure, but rather that
its currently a syntactical nightmare that makes code unreadable.

template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
what_type temp = t*u;
...

What should what_type be? Perhaps I'm not sufficiently familiar with
C++, but I'm unaware of any other syntax, nightmarical or otherwise,
that achieves the same effect as the new meaning that C++ has attached
to 'auto':

auto temp = t*u;

>The type of a numerical literal often depends upon the values of the
*_MAX macros from <limits.h>. Portable code cannot rely upon standard
typedefs such as size_t referring to any specific type, and it's a bad
idea to write code which makes assumptions about which type a
third-party typedef refers to. You can sometimes assume that the result
of an expression involving a typedef'd type will have the same type as
that typedef, but that's not always the case.

C++ will have to contend with this issue as well.

Yes, C++ has all the same opportunities that C has to be uncertain of
the type of an initializer expression. My point was that templates and
operator overloads make it orders of magnitude more likely to be a
problem in C++ than it is in C.

... If they have
decided its worth it, it seems like it would make perfect sense to
ride on their coat tails.

C is not C++, however great the overlap between the languages; the fact
that the new meaning for 'auto' is worth it's cost in C++ does not mean
that it's worth it in C.

.....

I don't think the rate of knowledge about the type of a declared
variable is all that different between C and C++. It may be more
confusing in C++, but the need to know exactly which one is basically
the same.

The need is the same; the feasibility of meeting that need is quite
different in the two languages.
....

>You talked about "leaving it alone for some future semantic extensions".

Yes, leaving open the possibility that the C++ idea can be adopted
later. Maybe waiting to see it proven in the C++ universe first or
just watching the Gnu C compiler adopt it as an extension for C as
well or whatever.

>If they're going to include such a change in a future version of the C
standard, then the first step should be to deprecate the current usage
of "auto", which is precisely what the committee has decided to do.

I don't follow the logic. Will C++ specifically require the
deprecation of the old use of auto to support its new usage?

It's not merely deprecated, the old usage of 'auto' is no longer
supported in n2723.pdf, the latest working draft I've picked up of the
next version of the C standard. I don't know whether there was an
intermediate version where the old usage was merely deprecated - I
stopped closely following the C++ standard's development a couple of
years ago. I think there should have been an intermediate version where
the old use was deprecated, and I would strongly favor the C committee
delivering at least one version where 'auto' is deprecated, before
delivering a version where it's current meaning disappears.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 18 Oct 2008 23:14:52 +0000, James Kuyper wrote:

the old usage of 'auto' is no longer
supported in n2723.pdf, the latest working draft I've picked up of the
next version of the C standard.

You had me confused there. I'm sure you meant to say n2723 is a draft of
the next version of the C++ standard.

[blargg]

In article <M5************ ****@nwrddc01.g nilink.net>, James Kuyper
<ja*********@ve rizon.netwrote:

Paul Hsieh wrote:

On Oct 18, 6:30 am, James Kuyper <jameskuy...@ve rizon.netwrote:

...

It is commonplace in C++ code to not be sure what the type of an
expression is. The biggest reason for this is templates; but the
overloading of functions is also a contributing factor. This makes the
new C++ meaning attached to "auto" very convenient.

As I understand it, this isn't a lack of being sure, but rather that
its currently a syntactical nightmare that makes code unreadable.

template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
what_type temp = t*u;
...

What should what_type be? Perhaps I'm not sufficiently familiar with
C++, but I'm unaware of any other syntax, nightmarical or otherwise,
that achieves the same effect as the new meaning that C++ has attached
to 'auto':

auto temp = t*u;

There is an ugly solution that's not very flexible, just mentioning it for
completeness:

template <typename T, typename U, typename what_typevoid func_ (
const T&t,
const U&u,
what_type temp
){
...
}

template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
func_( t, u, t*u );
}

[James Kuyper]

Harald van Dijk wrote:

On Sat, 18 Oct 2008 23:14:52 +0000, James Kuyper wrote:

>the old usage of 'auto' is no longer
supported in n2723.pdf, the latest working draft I've picked up of the
next version of the C standard.

You had me confused there. I'm sure you meant to say n2723 is a draft of
the next version of the C++ standard.

You are correct.

[James Kuyper]

blargg wrote:

In article <M5************ ****@nwrddc01.g nilink.net>, James Kuyper
<ja*********@ve rizon.netwrote:

[Re: planned new meaning for 'auto' in C++ - connection to planned
deprecation of 'auto' in C.]

>template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
what_type temp = t*u;
...

What should what_type be? Perhaps I'm not sufficiently familiar with
C++, but I'm unaware of any other syntax, nightmarical or otherwise,
that achieves the same effect as the new meaning that C++ has attached
to 'auto':

auto temp = t*u;

There is an ugly solution that's not very flexible, just mentioning it for
completeness:

template <typename T, typename U, typename what_typevoid func_ (
const T&t,
const U&u,
what_type temp
){
...
}

template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
func_( t, u, t*u );
}

Yes - "not very flexible" indeed.

[Anand Hariharan]

On Sat, 18 Oct 2008 10:21:32 -0700, Paul Hsieh <we******@gmail .comwrote:

On Oct 18, 6:30Â*am, James Kuyper <jameskuy...@ve rizon.netwrote:

(...)

>>
It is commonplace in C++ code to not be sure what the type of an
expression is. The biggest reason for this is templates; but the
overloading of functions is also a contributing factor. This makes the
new C++ meaning attached to "auto" very convenient.

As I understand it, this isn't a lack of being sure, but rather that its
currently a syntactical nightmare that makes code unreadable. (If you
are not sure today, and you type the wrong thing, your compiler will
tell you what you did wrong with an error message -- I sometimes
actually do this deliberately, when I am too lazy to look up the type.)
The purpose, I thought, was to respond to dynamic programming languages
which let you do away with specifying types.

>The benefits of such a change are much smaller in C. Not being certain
of the type of an expression is less common in C, though it can happen.

If we instead go with the "syntactica l nightmare" reason, we can see
that arrays of function pointers are types we would probably rather be
implicit.

>The type of a numerical literal often depends upon the values of the
*_MAX macros from <limits.h>. Portable code cannot rely upon standard
typedefs such as size_t referring to any specific type, and it's a bad
idea to write code which makes assumptions about which type a
third-party typedef refers to. You can sometimes assume that the result
of an expression involving a typedef'd type will have the same type as
that typedef, but that's not always the case.

C++ will have to contend with this issue as well. If they have decided
its worth it, it seems like it would make perfect sense to ride on their
coat tails.

>[...] However, in C you usually
have a pretty good idea what type an expression has. As a result, the
new C++ meaning for "auto" would be much less useful in C.

I don't think the rate of knowledge about the type of a declared
variable is all that different between C and C++. It may be more
confusing in C++, but the need to know exactly which one is basically
the same.

>The new C++ functionality of "auto" is moderately complicated;

Well, but this is due mostly to C++'s complications that don't exist in
C.

(...)

If anything, this thread in comp.lang.c++.m oderated, viz.,

MID: 47************* *@erdani.org

suggests introducing 'auto' could be murky in both C as well as C++.

- Anand