[Second reply attempt]

On 12/8/2010 08:30, restor wrote:
>
> Hi,
> FCD introduces a new "concept" into C++ language: a block with one
> return statement. It is used in two places: in lambdas to allow the
> deduction of return type and in constexpr functions.
> In lambdas the syntax is:
>         { attribute-specifier-seq<opt>  return<expression>  ; }
>
> In constexpr functions the syntax is:
>         { return<expression>  ; }
>
> The lack of optional attribute in return statement is an oversight, in
> my non-expert view, as in all other places the return statement is
> allowed to be attributed and there seams to be no reason to prohibit
> it in constexpr functions. If my observation is correct, the two could
> be generalized into a common syntactic entity: single-return-block.

The question is, whether the introduction of this term would really help
for the moment. Especially constexpr functions may undergo some
extensions (depending on the magnitude of them). Note that both function
return statements are also lacking the support for braced-init-lists. As of

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1048

these were considered as extensions not necessary for C++0x. Whether
braced-init-lists will be supported for constexpr functions is currently
debated, see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#837

Note also, that the return type deduction via auto and decltype
(possible in constexpr functions) also has subtle differences compared
to lambda auto return type deduction (see also #1048).

Additional to the suggestion shown in 837 there may or may not be  added
some support for static_assert and typedefs in constexpr functions, see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#898

On the other hand, for lambda expressions,

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#975

suggests to add multi-return statement auto deduction.

In other words: By enforcing a single normative term for both kinds of
return statements can stop progress for the individual evolutions. It
may turn out that both can be similarly handled, but IMO it is too early
to say that now.

> Further, in both places there is no point in disallowing additional
> typedef declarations and even variable declarations or even
> modifications to the variables. E.g. the following could be a valid
> single-return-block even in constexpr functions:
>
>         constexpr int add( int a, int b, int c )
>         {
>                 int tmp = a + b;
>                 tmp += c;
>                 return tmp;
>         }

I consider this suggestion as problematic - it completely deviates from
the concept of a generalized constant expression. Obviously 'tmp += c'
is none such constant expression. Even with the new term /function
invocation substitution/ (see [dcl.constexpr]/5 in the recent draft
n3225) this extension does not fit well. What about mutable functions of
user-defined literal types? Where would you stop to consider an
expression as no more being a constant expression? I see no reason why
there should be no requirement to transform above function into the
immutable form

          constexpr int add( int a, int b, int c )
          {
                  constexpr int tmp = a + b;
                  return tmp + c;
          }

though [Let me mention that the recently constexpr-ified duration
arithmetic functions as of [time.duration.nonmember] are defective in
this regard - I recently submitted a corresponding issue description to
the LWG]

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi,
FCD introduces a new "concept" into C++ language: a block with one
return statement. It is used in two places: in lambdas to allow the
deduction of return type and in constexpr functions.
In lambdas the syntax is:
       { attribute-specifier-seq<opt> return <expression> ; }

In constexpr functions the syntax is:
       { return <expression> ; }

The lack of optional attribute in return statement is an oversight, in
my non-expert view, as in all other places the return statement is
allowed to be attributed and there seams to be no reason to prohibit
it in constexpr functions. If my observation is correct, the two could
be generalized into a common syntactic entity: single-return-block.

Further, in both places there is no point in disallowing additional
typedef declarations and even variable declarations or even
modifications to the variables. E.g. the following could be a valid
single-return-block even in constexpr functions:

       constexpr int add( int a, int b, int c )
       {
               int tmp = a + b;
               tmp += c;
               return tmp;
       }

The above can be still thought of as one expression but "split" into a
number of statements for clarity or temporary re-use purposes. As long
as function does not contain statements that may make the function
skip the return statement or go to a different return statement or
risk the function not reaching the return statement, such as selection
statement, iteration statement or jump statement it should be as easy
to implement as a single expression. With this extended definition of
single-return-block, it could be reused in the third place in the next
standard (C++16 or such), once the concepts are added, for blocks in
axioms as proposed in N2887.

I propose to add optional attribute in return statement of constexpr
function, and merge the two similar syntaxes into single-return-block
still in C++0x as part of FCD cleanup. The other proposal could be an
interesting and useful extension for C++16.

Regards,
&rzej


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]