Francis Glassborow wrote:
>
> In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>, Herb Sutter
> <hsutter@acm.org> writes
> >I think this applies to the "auto" storage class issue, but I can't tell for
> >sure. If it does apply, then my answer above is correct, the standard is
> >inconsistent, and the normative text trumps the non-normative note. Any core
> >experts want to weigh in?
>
> Do you think the conflict is sufficient to merit a defect report? If so,
> I would be very happy to pursue the line that we should make the
> footnote correct by suitable wording in the normative text. IOWs I would
> like auto to suppress interpretation as a function declaration.
>

I don't think auto should be used to disambiguate.  What if I want
a static object:

  static std::vector<int>  kaye( long(i) );

Can I specify auto here to make this an object declaration?  The best
(and consistent) way to disambiguate this is to make the expression in
the direct initializer an unambiguous expression.

But I think a DR to remove the note in 7.1.1/2 is a good idea.

Mike

> Francis Glassborow      ACCU
> 64 Southfield Rd
> Oxford OX4 1PA          +44(0)1865 246490
> All opinions are mine and do not represent those of any organisation
>
>       [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
>       [ about comp.lang.c++.moderated. First time posters: do this! ]
>
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 995466416 27721 127.0.0.1 (18 Jul 2001 14:26:56
GMT)
X-Complaints-To: groups-support@google.com
NNTP-Posting-Date: 18 Jul 2001 14:26:56 GMT
Content-Length: 2331
X-UID: 0000000001
ReSent-Date: Wed, 18 Jul 2001 10:12:17 -0700 (PDT)
ReSent-From: Steve Clamage <clamage@eng.sun.com>
ReSent-To: c++-submit@netlab.cs.rpi.edu
ReSent-Message-ID: <Pine.SOL.3.96.1010718101217.11992A@taumet>

comeau@panix.com (Greg Comeau) wrote in message
news:<9j09c6$k8p$1@panix3.panix.com>...
> In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>,
> Herb Sutter  <hsutter@acm.org> wrote:
> >The original code:
> >>> >auto std::vector<int>  kaye( long(i) );
> >
> >I wrote:
> >>> The above line is not legal C++, because it's still parsed as a function
> >>> declaration (of a function named kaye taking a long and returning a
> >>> std::vector<int>), and an auto storage class is not allowed on a
function
> >>> return value.
> >
> >Both Dave Abrahams and Roger Orr quoted the note in 7.1.1/2:
> >>[Note: hence, the auto specifier is almost always redundant and not
> >>often used; one use of auto is to distinguish a declaration-statement
> >>from an expression-statement (6.8) explicitly. --end note]
> >
> >Well, clearly what I've believed to be true conflicts with the
non-normative
> >note in 7.1.1/2 -- one must be wrong. Note that the referred-to section
> >6.8/3 includes this normative statement:
> >
> >  Disambiguation precedes parsing, and a statement disambiguated as a
> >  declaration may be an ill-formed declaration.
> >
> >I think this applies to the "auto" storage class issue, but I can't tell
for
> >sure. If it does apply, then my answer above is correct, the standard is
> >inconsistent, and the normative text trumps the non-normative note. Any
core
> >experts want to weigh in?
> >
> >Incidentally, I've tried this on four compilers. All agree with my
> >understanding, not with the note, so at least if I've got it wrong I'm in
> >good company. Normally, "what compilers do" is hardly definitive, but in
> >this case one of the compilers I tried is Comeau, which uses EDG, and EDG
is
> >usually the next best thing to definitive when it comes to core language
> >interpretation issues...
>
> IMO, everybody is partially right here.  That is, I think you're just
> reading too much into the [Note...]   It does not say that auto
> distinguishes all possible contexts, just some.
>

In particular, it does *not* say it disambiguates local variable
definitions from function declarations, which is what the example is
about. It says that it can be used to explicitly disambiguate
declaration statements from expression statements. In other words, its
not even relevant to the case in point.

Mark Williams



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

markw65@my-deja.com (Mark Williams) wrote in message news:<10f784d5.0107180626.2a36cfec@posting.google.com>...

[snip]
> > IMO, everybody is partially right here.  That is, I think you're just
> > reading too much into the [Note...]   It does not say that auto
> > distinguishes all possible contexts, just some.

But we don't seem to have found such an example yet.
If such an example does not exist can we remove the note?

> In particular, it does *not* say it disambiguates local variable
> definitions from function declarations, which is what the example is
> about. It says that it can be used to explicitly disambiguate
> declaration statements from expression statements. In other words, its
> not even relevant to the case in point.

Well, the relevant section 8.2p1 [dcl.ambig.res] Ambiguity resolution
starts with "The ambiguity arising from the similarity between a
function   style cast and a declaration mentioned in 6.8 can also occur
in the context of a declaration."
So it doesn't seem clear to me whether the 7.1.1/2 note applies here
or not...

I was assuming the note does apply here - if not, can anyone suggest
an example of the 7.1.1/2 note in the 6.8 context of disambiguating
expressions vs declarations?

[My preference is removal of the note rather than Francis' suggestion
of trying to get auto to disambiguate since the note to 8.2p1 already
lists several ways to explicitly disambiguate function and object
declarations.]

--
Roger Orr
MVP in C++ at www.brainbench.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <10f784d5.0107180626.2a36cfec@posting.google.com>,
Mark Williams <markw65@my-deja.com> wrote:
>comeau@panix.com (Greg Comeau) wrote in message
>news:<9j09c6$k8p$1@panix3.panix.com>...
>> In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>,
>> Herb Sutter  <hsutter@acm.org> wrote:
>> >The original code:
>> >>> >auto std::vector<int>  kaye( long(i) );
>> >
>> >I wrote:
>> >>> The above line is not legal C++.....
>> >Both Dave Abrahams and Roger Orr quoted the note in 7.1.1/2:
>> >>[Note: hence, the auto specifier is almost always redundant and not
>> >>often used; one use of auto is to distinguish a declaration-statement
>> >>from an expression-statement (6.8) explicitly. --end note]
>>
>> IMO, everybody is partially right here.  That is, I think you're just
>> reading too much into the [Note...]   It does not say that auto
>> distinguishes all possible contexts, just some.
>>
>
>In particular, it does *not* say it disambiguates local variable
>definitions from function declarations, which is what the example is
>about. It says that it can be used to explicitly disambiguate
>declaration statements from expression statements. In other words, its
>not even relevant to the case in point.

IMO, it's just a general statement, and so _looks_ like it could apply.
Compounded on that, some compilers allow it (or did allow it) to
disambiguate the example above... if I recall correctly.

Anyway, I'm not convinced the note is wrong, but at best, it doesn't
seem to help much either.
--
Greg Comeau                 Countdown to "export": December 10, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo, now for Windows too! Try out our C99 mode!
Special July "2fer", see http://www.comeaucomputing.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

comeau@panix.com (Greg Comeau) wrote (abridged):
> I don't know when the above [Note..] was added into the Standard,
> but some drafts of C++ did allow implicit int.   That means
> with something like this:
>
> int exprOrDeclA = 99;
> int exprOrDeclB = -99;
>
> int main()
> {
>     exprOrDeclA;
>     auto exprOrDeclB;
> }
>
> Clearly, we see that we can change the meaning with auto,
> as least as I recall it.   Anyway, the B form is no longer allowed.
> (And I'm not recommending either version even if it were.)

I imagine this stuff has implications for the idea of using "auto" to
signify type inference. Eg:

      exprOrDeclA = 1.0; // Assignment
      auto exprOrDeclB = 1.0; // Declaration of a double.

where the missing type is implicitly filled in with the type of the
expression which initialises it. I am quite keen on this, especially for
things like:

    for (auto i = table.begin(); i != table.end(); ++i)
        ...

I hope the deliberations in this thread don't rule out this possible
future feature. (Assuming it's feasible today.)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

| In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>, Herb Sutter
| <hsutter@acm.org> writes
| >I think this applies to the "auto" storage class issue, but I can't tell for
| >sure. If it does apply, then my answer above is correct, the standard is
| >inconsistent, and the normative text trumps the non-normative note. Any core
| >experts want to weigh in?
|
| Do you think the conflict is sufficient to merit a defect report?

I don't see anything in the normative part which supports the
non-normative note.  Either we agree that the non-normative part is
just that: Non-normative; then we should correct it to be in agreement
with the normative text. Or we think that the non-normative part was
indeed intented, but the committee failed to provide the appropriate
wordings; then again a DR need to be filed.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>,
Herb Sutter  <hsutter@acm.org> wrote:
>The original code:
>>> >auto std::vector<int>  kaye( long(i) );
>
>I wrote:
>>> The above line is not legal C++, because it's still parsed as a function
>>> declaration (of a function named kaye taking a long and returning a
>>> std::vector<int>), and an auto storage class is not allowed on a function
>>> return value.
>
>Both Dave Abrahams and Roger Orr quoted the note in 7.1.1/2:
>>[Note: hence, the auto specifier is almost always redundant and not
>>often used; one use of auto is to distinguish a declaration-statement
>>from an expression-statement (6.8) explicitly. --end note]
>
>Well, clearly what I've believed to be true conflicts with the non-normative
>note in 7.1.1/2 -- one must be wrong. Note that the referred-to section
>6.8/3 includes this normative statement:
>
>  Disambiguation precedes parsing, and a statement disambiguated as a
>  declaration may be an ill-formed declaration.
>
>I think this applies to the "auto" storage class issue, but I can't tell for
>sure. If it does apply, then my answer above is correct, the standard is
>inconsistent, and the normative text trumps the non-normative note. Any core
>experts want to weigh in?
>
>Incidentally, I've tried this on four compilers. All agree with my
>understanding, not with the note, so at least if I've got it wrong I'm in
>good company. Normally, "what compilers do" is hardly definitive, but in
>this case one of the compilers I tried is Comeau, which uses EDG, and EDG is
>usually the next best thing to definitive when it comes to core language
>interpretation issues...

IMO, everybody is partially right here.  That is, I think you're just
reading too much into the [Note...]   It does not say that auto
distinguishes all possible contexts, just some.

I don't know when the above [Note..] was added into the Standard,
but some drafts of C++ did allow implicit int.   That means
with something like this:

int exprOrDeclA = 99;
int exprOrDeclB = -99;

int main()
{
    exprOrDeclA;
    auto exprOrDeclB;
}

Clearly, we see that we can change the meaning with auto,
as least as I recall it.   Anyway, the B form is no longer allowed.
(And I'm not recommending either version even if it were.)
Of course too though, this is allowed:

    int (identifier);

and so using:

    auto int (identifier);

is allowed, though certainly removing the parens
altogether seems the best approach (though that's not
always as obvious in an involved function or pointer to
function declaration).

Also I do believe that some compilers allow auto as an extension
_or perhaps as a bug_ and so auto might be useful in those
non-standard cases.
--
Greg Comeau                 Countdown to "export": December 10, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo, now for Windows too! Try out our C99 mode!
Special July "2fer", see http://www.comeaucomputing.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>, Herb Sutter
> <hsutter@acm.org> writes
> >I think this applies to the "auto" storage class issue, but I can't tell for
> >sure. If it does apply, then my answer above is correct, the standard is
> >inconsistent, and the normative text trumps the non-normative note. Any core
> >experts want to weigh in?
>
> Do you think the conflict is sufficient to merit a defect report? If so,
> I would be very happy to pursue the line that we should make the
> footnote correct by suitable wording in the normative text. IOWs I would
> like auto to suppress interpretation as a function declaration.
>

I don't think auto should be used to disambiguate.  Clearly, auto
can't be used if I wish to define a static object:

  static std::vector<int>  kaye( long(i) );

This is function declaration.  The better way to make this an object
definition is to make the expression in the direct initializer an
unambiguous expression.

I think it would be very strange if by changing the storage specifier I
get an object definition:

  static int x( long(i) );   // function declaration
  auto   int x( long(i) );   // object definition

Storage specifiers should only change the storage duration of the
entity being declared.  They should not influence parsing.

Mike
--
http://www.lazycplusplus.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B554F88.125B3415@btclick.com>, Michael Spencer
<michael_spencer@btclick.com> writes
>I don't think auto should be used to disambiguate.  Clearly, auto
>can't be used if I wish to define a static object:
>
>  static std::vector<int>  kaye( long(i) );

We can do anything we choose to do. In fact if we removed auto form the
language the impact would be as close to zero as we can get (can anyone
produce a piece of code that would be altered, other than lexically, by:

#define auto

)

This means that auto is effectively a free keyword, a hangover form the
past.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

The original code:
>> >auto std::vector<int>  kaye( long(i) );

I wrote:
>> The above line is not legal C++, because it's still parsed as a function
>> declaration (of a function named kaye taking a long and returning a
>> std::vector<int>), and an auto storage class is not allowed on a function
>> return value.

Both Dave Abrahams and Roger Orr quoted the note in 7.1.1/2:
>[Note: hence, the auto specifier is almost always redundant and not
>often used; one use of auto is to distinguish a declaration-statement
>from an expression-statement (6.8) explicitly. --end note]

Well, clearly what I've believed to be true conflicts with the non-normative
note in 7.1.1/2 -- one must be wrong. Note that the referred-to section
6.8/3 includes this normative statement:

  Disambiguation precedes parsing, and a statement disambiguated as a
  declaration may be an ill-formed declaration.

I think this applies to the "auto" storage class issue, but I can't tell for
sure. If it does apply, then my answer above is correct, the standard is
inconsistent, and the normative text trumps the non-normative note. Any core
experts want to weigh in?

Incidentally, I've tried this on four compilers. All agree with my
understanding, not with the note, so at least if I've got it wrong I'm in
good company. Normally, "what compilers do" is hardly definitive, but in
this case one of the compilers I tried is Comeau, which uses EDG, and EDG is
usually the next best thing to definitive when it comes to core language
interpretation issues...

Herb

---
Herb Sutter (http://www.gotw.ca)

Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <1n8sktsoubborh5rnl7eaqr1f32sfm337g@4ax.com>, Herb Sutter
<hsutter@acm.org> writes
>I think this applies to the "auto" storage class issue, but I can't tell for
>sure. If it does apply, then my answer above is correct, the standard is
>inconsistent, and the normative text trumps the non-normative note. Any core
>experts want to weigh in?

Do you think the conflict is sufficient to merit a defect report? If so,
I would be very happy to pursue the line that we should make the
footnote correct by suitable wording in the normative text. IOWs I would
like auto to suppress interpretation as a function declaration.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]