5

Ago, Some rules in the standard that say they are applied to expression, I was confused about whether these rules can also be applied to full-expression arbitrarily. I get an answers in that question. However, there are some rules like "the full-expression of the initialization shall be a constant expression. " in the standard. Such as:
dcl.constexpr#9
basic.start.static#2

They all say that the full-expression must be a constant expression in these above links.
The prior condition for a constant expression is it must be a core constant expression which is first an expression. We know these rules in expr.const#2 are applied to expression, not to full-expression which is not an expression.

An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine, would evaluate one of the following expressions:

However init-declarator which is the form declarator initializer(opt) is not an expression. So how to interpret a full-expression of the intialization is a constant expression? Or, the sentence in the standard means that these expressions within the full-expression all must be constant expressions?

xmh0511
  • 7,010
  • 1
  • 9
  • 36
  • Hi once again. A full-expression is an expression. Once again it is a very important concept defined here: http://eel.is/c++draft/intro.execution#5.6 – Oliv May 31 '20 at 20:12
  • 1
    The unnecessary "full" adjective is certainly here to insist that also any convertion function that may implicitly participate in the initialization are part of the initialization. The standard somehow already insist on this : http://eel.is/c++draft/intro.execution#5.sentence-4. Maybe there have been some misunderstanding and they decided not to let window open to interpretation. You realy should not care about superfluous adjective, sometime entire sentences in the standard. There are paragraphs that looks like poetry, other too much concises, and that judgement depend on the reader. – Oliv May 31 '20 at 20:22
  • @Oliv a part of a full-expression is not a full-expression, such as performing initialization. Some rules that apply to expressions can't apply to full-expressions arbitrarily, otherwise, how do you interpret these comments, [link1](https://stackoverflow.com/questions/62077796/is-an-init-declarator-a-prvalue-expression/62078121#comment109793552_62077796) , [link2](https://stackoverflow.com/questions/62077796/is-an-init-declarator-a-prvalue-expression/62078121#comment109793866_62077796) – xmh0511 Jun 01 '20 at 01:47
  • @Oliv I'm sorry. What I want to say is that a full-expression may an expression.I also say these rules apply to expressions can't apply to full-expression **arbitrarily**(if the full-expression is not an expression), i.e,Not all full-expression are expressions, such as, `func()` is a full-expression but also an expression, so the rules that apply to expressions can also apply to it, something just like this. For `int a = 0;`,the `init-declarator` is a full-expression but not an expression, So you can't apply some rules for an expression to this full-expression. – xmh0511 Jun 01 '20 at 05:16
  • @Oliv ago, I also considered a full-expression is an expression, however they indeed have some distinctions, which are expressions are all listed in the [expression] section, please look at this answers. – xmh0511 Jun 01 '20 at 14:00
  • you forgot the link in your last comment. – Oliv Jun 01 '20 at 14:24
  • a+b; is a full expression. The meaning of this full expression is defined in [expression] defines the grammar of expression and describe what is the result of the evaluation of expression with builtin meaning... `a_type v = a + b`, part of this full expression is decribed in [expression] other part in [dcl.init]. Nevertheless if by reading [dcl.init] one find that a conversion of a+b is performed and if this conversion is a standard conversion... it is described in [expression]. You realy try to give a sence to the standard organization that it does not have. – Oliv Jun 01 '20 at 14:35
  • @Oliv [link](https://stackoverflow.com/a/62078121/11796722) is here, "a+b" within the full-expression is indeed an expression which is mentioned in [expreesion], and it's a part of the full-expression. – xmh0511 Jun 01 '20 at 14:46
  • You have remarked the terms used in the answer, parsing, grammar, the answer is about parsing. A full-expression is not a grammar rule. A full-expression is realy about the evaluation of the expression or the initializer... A full-expression does not tell the compiler how to parse code. But it how should be performed evaluation: two full-expression evaluation cannot overlap. In [expression] parsing and builtin evaluation definition is mixed-up. In expr.const, is just about evaluation, this part of the standard does not describe how code should be parsed. – Oliv Jun 01 '20 at 15:01
  • Interrestingly this is the same trouble you had in the last question an answer to you. This is true that inside the standard, the parsing phase, and the description of the actual meaning is somehow mixed-up, sometime from one sentence to the other without any transition.. – Oliv Jun 01 '20 at 15:05
  • @Oliv you mean that the rules for evalution can also be applied to a full-expression, such as these rules in [expression.const]? – xmh0511 Jun 01 '20 at 15:09
  • 2
    When evaluation is the concern, a full-expression is an expression, otherwise a full-expression is just not a grammar rule so all what is in expr.const applies to full expression. – Oliv Jun 01 '20 at 15:11
  • And this http://eel.is/c++draft/expr.const#2.2, is here to actually deal about what concerns you – Oliv Jun 01 '20 at 15:14
  • @Oliv thanks, maybe I misread the answers in that question. That is to say, if the parsing is concerned, the rules mentioned in [expression], such as, determine the value category of an expression can only be applied to an expression which is listed in [expression] , or to a full-expression which is an expression that be listed in [expression], Right? – xmh0511 Jun 01 '20 at 15:24
  • @Oliv However, "A prvalue is an expression whose evaluation initializes an object", it's about evalution, so, why an init-declarator does not have a value category(it's a full-expression). – xmh0511 Jun 01 '20 at 15:40
  • An init-declarator is just a grammar rule. It is a statment. The full-expression is just about the evaluation. The evaluation of the code that result from the parsing of the init-declarator, is the initialization. When a full expression is said to be an "init-declarator" actualy, the writter of the standard was actualy talking about the expression that performs the initialization. This is a figure of speech called metonymy. This is quite usual, maybe you are the first guy on earth who noticed this one. – Oliv Jun 01 '20 at 15:52
  • @Oliv Hi, guy.Couldn't you answer my asking directly? :-) , you mean that `init-declarator` indeed a prvalue expression? – xmh0511 Jun 02 '20 at 01:31
  • @NicolBolas paging NicolBolas – xmh0511 Jun 02 '20 at 03:03
  • a constexpr function must be so simple that the compiler (every standard-conforming compiler) can evaluate it and also it shouldn't modify anything outside the scope of the expression. – djacob Jun 06 '20 at 12:39
  • @djacob Hi, it does not interpret this question. – xmh0511 Jun 06 '20 at 13:53
  • 1
    @Oliv An init-declarator is a full-expression and not an expression, so your comment "A full-expression is an expression" is demonstrably false – M.M Jun 19 '20 at 02:39
  • @M.M Totally agree. I infer it may be a defect in the standard, and what actually the standard intent to say is that each evaluation of expression in the **full-expression** must satisfy these requirements of a constant-expression. However, I'm unable to determine this. So I want to look up a knowledge man that can answer this question. – xmh0511 Jun 19 '20 at 03:03
  • @M.M. If you consider that the term "expression" refers to a grammar rule, a full-expression does not refer to a grammar rule so a "full-expression" is not an expression. On the other hand. A full-expression can be a constant-expression and a constant-expression is a conditional-expression so it is an expression. So an expression is not always an expression. The huge trouble is that a full-expression never refer to a grammar rule, nor is the term expression inside [const.expr] or only if it is formated as a grammar rule. Those term refer to an evaluation. – Oliv Jun 19 '20 at 10:49
  • If you read the begining of [expr] there are some kind of guard against poeple who are confunding the referent and referee, I'll find you it later. I have always wondered why they wrote it. I suppose to help reading for poeple who have not enough experiment to deduce the contextual information. – Oliv Jun 19 '20 at 10:51
  • @Oliv I consider that "expression" refers to expressions – M.M Jun 19 '20 at 11:00
  • @M.M. I reminber that someone was once confused because of that: "http://eel.is/c++draft/expr#basic.lval-5.sentence-3" "A prvalue whose result is the value V is sometimes said to have or name the value V". – Oliv Jun 19 '20 at 11:59
  • @M.M. Actualy here the problem is :"the full-expression of its initialization is a constant expression when interpreted as a constant-expression, " [expr.const]/2.2. And "constant-expression" in this sentence is a grammar rule.... What ??? But full-expression is not a grammar rule and it does not make sense to try to parse it. – Oliv Jun 19 '20 at 12:07
  • @M.M. A full-expression is defined in "Sequential execution", in its definition we find: "an init-declarator or a mem-initializer, including the constituent expressions of the initializer," or "If a language construct is defined to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this definition". This is clear a full-expression is not meant to refer to a grammar rule. It is realy only about the meaning of an expression. – Oliv Jun 19 '20 at 12:08
  • @M.M. The term expression sometime refers to "the syntax, order of evaluation, and meaning of expressions" [expr.pre]/1. And a full-expression is only about the meaning. As such an full expression is an expression (when only refering to the meaning). – Oliv Jun 19 '20 at 12:08
  • @M.M. And whatsoever this is english grammar adj-noum is a noum. – Oliv Jun 19 '20 at 12:09
  • @Oliv There is no [expr.pre] in the C++17 standard. Also the text " "the syntax, order of evaluation, and meaning of expressions" appears in [expr]/1 and does not form part of the definition of "expression" (which comes in the next sentence). (and is non-normative text) – M.M Jun 19 '20 at 12:38
  • @M.M. I remimber that an old coder told me that 30 years ago, they believed that thanks to object-oriented programming specification could be directly mapped to code.... The trouble is that abstractions do not always map to objects and terms have a meaning that depends on the context. Hopefully english is not a formal system. – Oliv Jun 22 '20 at 09:42
  • Somewhat related WG14 defect report (for C, _not_ C++): [WG14 - DR 439 - Issues with the definition of “full expression”](http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_439). – dfrib Jun 24 '20 at 10:17

0 Answers0