New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistencies with "object declarations", "declarations that declare objects" and "class members of object type" #1280
Comments
I would like to mention that it even calls "extern void(&r)();" an "object declaration". This is where the analogy with "object pointer" breaks down and IMO the very least that should be done with this term is to ensure that references to functions are not included. |
It seems to me that [dcl.dcl]/10 is rather explicit that the world of (simple-)declarations has three partitions: typedef declarations, function declarations, and object declarations. The latter term therefore includes "reference to function" declarations. This distinction seems to be mostly used in [dcl.ambig.res] (correctly, it seems) plus a single use in [dcl.constexpr]. ( "declaration of an object" seems to be used only in notes and in [basic]/6. My suggestion would be to add a note in [dcl.dcl]/10 highlighting the fact that "object declaration" also applies to references, even though they are not objects. And maybe rephrase the use in [dcl.constexpr] so that we're using more explicit terms there. |
Am 27.12.2016 23:07 schrieb "Jens Maurer" <notifications@github.com>:
It seems to me that [dcl.dcl]/10 is rather explicit that the world of
(simple-)declarations has three partitions: typedef declarations, function
declarations, and object declarations. The latter term therefore includes
"reference to function" declarations. This distinction seems to be mostly
used in [dcl.ambig.res] (correctly, it seems) plus a single use in
[dcl.constexpr]. (constexpr on a reference declaration does make sense; it
guarantees compile-time evaluation of the lvalue to which the reference
binds.
In dcl.constexpr, the text goes on to say "declares the object to be
const", which needs correction.
Other than that, I think your suggestion with clarifying that "object
declaration" also applies to declarations of references and to data-member
declarations would seem to work, even if highly ambiguous. I was thinking
about "variable declaration". But a variable declaration that sometimes
doesn't declare a variable is just as awful.
|
Perhaps it would be worthwhile to specify what "a declaration of an object" is explicitly. |
Addtionally, it should be specified that a declaration of a static data member is the declaration of an object (as of now, it just declares a member) |
Editorial meeting: Address as a CWG issue. |
Richard asked me to add the following std-discussion content as an issue (the original question was about "A variable is introduced by the declaration of a reference other than a non-static data member or of an object.").
OK, thanks I see. But, is this intent worded somewhere in the spec
aswell? As far as declarations that contain decl-specifier-seq are
concerned we have at 7p10 that says
Am am not totally sure whether this only applies to
simple-declarations (because of the location of that paragraph), or
whether it applies to all declarations that contain
decl-specifier-seqs. Another thing is, because it indicate that an
"object declaration" is not quite the same as a "declaration of an
object", it becomes very involved. Are the following summaries correct
based on your answers and the spec?
Are they correct concerning the intent? Would it not make sense to
distinguish between object declarations and reference declarations?
Other places in the spec seem to use "object declaration" as implying
that they declare objects, like 7.1.5p9:
On the other hand, there's evidence that other places use "object
declaration" to mean "declaration that gives names an object or
reference type", such as 8.2p1:
This indicates that this term "object declaration" was not updated
properly when references were added to the language?
The text was updated successfully, but these errors were encountered: