Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Empty parameter list not optional for mutable lambdas?

29 views
Skip to first unread message

Scott Meyers

unread,
Jul 2, 2009, 3:08:23 AM7/2/09
to
For whatever reason, lambdas may omit the parameter list if there are
no parameters. But only for non-mutable lambdas. Mutable lambdas
must always provide a parameter list. For example:

int main()
{
int x;
auto f1 = [&]() { x; }; // fine, empty parameter list
auto f2 = [&] { x; }; // fine, no parameter list
auto f3 = [&]() mutable { ++x; }; // fine, empty parameter list
auto f4 = [&] mutable { ++x; }; // error! missing parameter list
}

I can't help but ask: why can't an empty parameter list be omitted for
a mutable lambda? (Okay, at one level I know: it's in the grammar.
But why?)

Thanks,

Scott

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

SG

unread,
Jul 2, 2009, 12:56:32 PM7/2/09
to
On 2 Jul., 09:08, Scott Meyers <use...@aristeia.com> wrote:
> For whatever reason, lambdas may omit the parameter list if there are
> no parameters. But only for non-mutable lambdas. Mutable lambdas
> must always provide a parameter list. For example:
>
> int main()
> {
> int x;
> auto f1 = [&]() { x; }; // fine, empty parameter list
> auto f2 = [&] { x; }; // fine, no parameter list
> auto f3 = [&]() mutable { ++x; }; // fine, empty parameter list
> auto f4 = [&] mutable { ++x; }; // error! missing parameter list
> }

This is not an answer to your question, just an observation. Since

struct foo
{
int& x;
explicit foo(int& x) : x(x) {}
void operator()() const {++x;}
};

is well-formed (x can be modified in a const member function) I would
assume that

auto f5 = [&] { ++x; };

is also well-formed and doesn't require "mutable". You only require
mutable if you capture something by value and want to modify it.

Cheers!
SG

Daveed

unread,
Jul 2, 2009, 7:12:18 PM7/2/09
to
On Jul 2, 3:08 am, Scott Meyers <use...@aristeia.com> wrote:
> For whatever reason, lambdas may omit the parameter list if there are
> no parameters. But only for non-mutable lambdas. Mutable lambdas
> must always provide a parameter list. For example:
>
> int main()
> {
> int x;
> auto f1 = [&]() { x; }; // fine, empty parameter list
> auto f2 = [&] { x; }; // fine, no parameter list
> auto f3 = [&]() mutable { ++x; }; // fine, empty parameter list
> auto f4 = [&] mutable { ++x; }; // error! missing parameter list
>
> }
>
> I can't help but ask: why can't an empty parameter list be omitted for
> a mutable lambda? (Okay, at one level I know: it's in the grammar.
> But why?)


I don't recall how we got there or even if this was explicitly
discussed after the initial proposal (it probably was because the
lambda syntax was debated extensively).

That said, I think the limitation makes sense: "mutable" is a property
of the operator() in the closure type (and not, for example, of the
closure object or the closure type itself). When that operator() is in
evidence through the explicit parameter list, the syntax reflects
that. But when there is no parameter list, the connection of
"mutable" to operator() is more obscure IMO.

I also think that "mutable" is unlikely to be useful for one-statement
lambdas. (E.g., in your example I cannot think of a reason to add
"mutable".) In fact, I cannot think of a useful case of "mutable" in a
lambda that cannot reflect the implied potential state change through
a parameter or return type.

Daveed

Scott Meyers

unread,
Jul 3, 2009, 2:26:31 AM7/3/09
to
SG wrote:
> This is not an answer to your question, just an observation. Since
>
> struct foo
> {
> int& x;
> explicit foo(int& x) : x(x) {}
> void operator()() const {++x;}
> };
>
> is well-formed (x can be modified in a const member function)

I didn't realize that, thanks for pointing it out.

> I would assume that
>
> auto f5 = [&] { ++x; };
>
> is also well-formed and doesn't require "mutable".

This seems reasonable, and VC10 agrees with you.

> You only require
> mutable if you capture something by value and want to modify it.

So it would appear.

Scott

Scott Meyers

unread,
Jul 3, 2009, 11:14:49 AM7/3/09
to
Daveed wrote:
> that. But when there is no parameter list, the connection of
> "mutable" to operator() is more obscure IMO.

It hardly makes it any more obscure than it already is. After all, this is
pretty much the only place in the language where we use mutable to turn off
constness that was never expressly applied in the first place. (As far as I
know, the only exception to this is string literals, which are arrays of const
[character type], even though the word "const" is never used. It's worth noting
that other literals are not implicitly const, e.g., the type of 22 is int, not
const int.)

Because my job largely consists of (1) learning the rules governing C++ and (2)
explaining them to other people, I place a premium on consistency in the
language. It makes both parts of my job easier, and, to be honest, I think it
makes life easier for developers, too. In this case, I'd like to be able to say

Parameterless lambdas may omit the parameter list.

Instead, I have to say (and they have to remember)

Non-mutable lambdas may omit the parameter list.

I also have to be prepared to try to explain why mutable lambdas don't follow
the same rule as non-mutable lambdas.

Scott

Gabriel Dos Reis

unread,
Jul 3, 2009, 3:59:37 PM7/3/09
to
Scott Meyers <use...@aristeia.com> writes:

| Daveed wrote:
| > that. But when there is no parameter list, the connection of
| > "mutable" to operator() is more obscure IMO.
|
| It hardly makes it any more obscure than it already is. After all, this is
| pretty much the only place in the language where we use mutable to turn off
| constness that was never expressly applied in the first place.

Sure, but we have learnt a lot over the decades and it is arguable where
'const' should not be the default all the time.

| (As far as I
| know, the only exception to this is string literals, which are arrays of const
| [character type], even though the word "const" is never used. It's worth noting
| that other literals are not implicitly const, e.g., the type of 22 is int, not
| const int.)

It is debatable whether it should should not be 'const int' :-)

|
| Because my job largely consists of (1) learning the rules governing C++ and (2)
| explaining them to other people, I place a premium on consistency in the
| language.

I sympathsize. Did you consider joining the forces of the committee,
participate in committee meetings and work, and having a voice that
constructively bend the arc in the direction you consider most
appropriate at the time the committee was still debating the issue?

Scott Meyers

unread,
Jul 5, 2009, 2:26:31 AM7/5/09
to
Gabriel Dos Reis wrote:
> Sure, but we have learnt a lot over the decades and it is arguable where
> 'const' should not be the default all the time.

Sure, and it'd be an interesting argument to have if we were starting from
scratch. But we're not starting from scratch, and we can't use const as
the
default "all the time" in C++, because that would break virtually every
program
in existence. The default was chosen about 25 years ago, and that decision
can't, practically speaking, be undone. All we can do now is change the
default
for completely new things, and doing that inherently introduces yet another
inconsistency into a language that either is or should be famous for them.

> It is debatable whether it should should not be 'const int' :-)

I'm sure it is :-)

> I sympathsize. Did you consider joining the forces of the committee,

Many times. But as I wrote to a colleague recently who more or less
asked the
same question:

> There are a lot of jobs surrounding C++, and the one I happen to have
> fallen into is explanation. Other people focus on implementation,
> standardization, extension, etc. I know that there is a lot of work to
> do on standardization, and I feel somewhat guilty that I don't
contribute
> to it. I feel especially guilty when people like you spend the time to
> help me get my job done, yet I don't contribute to the standardization
> burden. At the same time, I recognize that standardization is hard,
> exacting, time-consuming work, and, like you and many others, I'm
already
> oversubscribed.

Each of us has to decide how to spend the limited time and energy we have
available. For better or for worse, I've decided that participating in C++
standardization is too demanding an endeavor to add to the other
obligations I
carry.

Scott

Gabriel Dos Reis

unread,
Jul 5, 2009, 7:08:07 PM7/5/09
to
Scott Meyers <use...@aristeia.com> writes:

| Gabriel Dos Reis wrote:
| > Sure, but we have learnt a lot over the decades and it is arguable where
| > 'const' should not be the default all the time.
|
| Sure, and it'd be an interesting argument to have if we were starting from
| scratch. But we're not starting from scratch, and we can't use const as

Many new ideas in C++0x are no just incremental fiddling with small
details. I understand the argument of 'foolish consistency'. But I'm
skeptical that in 21st century C++ it should systematically
overrule and sbotage sound ideas.

| the
| default "all the time" in C++, because that would break virtually every
| program in existence.

Understood. But that argument alone does not imply that we should not
use 'const as default' when we can. It would be nice it everything were
regular, but the real world is not -- and that is part of the price we
pay for living with history.

| The default was chosen about 25 years ago, and that decision
| can't, practically speaking, be undone.

However, in many cases, we can apply lessons learnt from the past while
looking foward to the future.


| All we can do now is change the default
| for completely new things, and doing that inherently introduces yet
another
| inconsistency into a language that either is or should be famous for them.

Maybe.

| > It is debatable whether it should should not be 'const int' :-)
|
| I'm sure it is :-)
|
| > I sympathsize. Did you consider joining the forces of the committee,
|
| Many times.
|
| But as I wrote to a colleague recently who more or less
| asked the same question:
|
| > There are a lot of jobs surrounding C++, and the one I happen to have
| > fallen into is explanation. Other people focus on implementation,
| > standardization, extension, etc. I know that there is a lot of
work to
| > do on standardization, and I feel somewhat guilty that I don't
| contribute
| > to it. I feel especially guilty when people like you spend the
time to
| > help me get my job done, yet I don't contribute to the standardization
| > burden. At the same time, I recognize that standardization is hard,
| > exacting, time-consuming work, and, like you and many others, I'm
| already
| > oversubscribed.

Indeed.

| Each of us has to decide how to spend the limited time and energy we have
| available.

Agreed.

| For better or for worse, I've decided that participating in C++
| standardization is too demanding an endeavor to add to the other
| obligations I
| carry.

I fully sympathize -- most of the C++ standard committee members have
lot of various obligations in addition to getting the job done.

On the other hand, choosing to stay outside the standardization process
is a sure way not to participate in the decision making process when the
future of the language is being defined.

Nevin :-] Liber

unread,
Jul 6, 2009, 3:09:45 PM7/6/09
to
In article <873a9bx...@gauss.cs.tamu.edu>,

Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

> | The default was chosen about 25 years ago, and that decision
> | can't, practically speaking, be undone.
>
> However, in many cases, we can apply lessons learnt from the past while
> looking foward to the future.

One of those lessons *is* consistency.


I remember back in the 80s (before the C standard was finalized)
questioning why one could have an optional comma at the end of a struct
initialization list but not one at the end of an enumeration list.

I was told by a committee member that because they were different kinds
of lists, the syntax could be different. In other words, this was a
deliberate decision not to be consistent.

I've always wondered what feature we could have gotten if the committee
had initially made that consistent instead of having to spend the time
to correct their mistake later.


The bar for breaking consistency should be about as high as the bar for
adding a new keyword.

--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> 773 961-1620

Gabriel Dos Reis

unread,
Jul 6, 2009, 8:14:41 PM7/6/09
to
"Nevin :-] Liber" <ne...@eviloverlord.com> writes:

| In article <873a9bx...@gauss.cs.tamu.edu>,
| Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
|
| > | The default was chosen about 25 years ago, and that decision
| > | can't, practically speaking, be undone.
| >
| > However, in many cases, we can apply lessons learnt from the past while
| > looking foward to the future.
|
| One of those lessons *is* consistency.

Where would you draw the line between 'consistency with known broken
defaults' and 'willful ignorance of improvement opportunities'?

[...]

| The bar for breaking consistency should be about as high as the bar for
| adding a new keyword.

I would think it depends on the what one has to be consistent with.

--

Hendrik Schober

unread,
Jul 8, 2009, 12:48:31 AM7/8/09
to
Gabriel Dos Reis wrote:
> "Nevin :-] Liber" <ne...@eviloverlord.com> writes:
>
> | In article <873a9bx...@gauss.cs.tamu.edu>,
> | Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> |
> | > | The default was chosen about 25 years ago, and that decision
> | > | can't, practically speaking, be undone.
> | >
> | > However, in many cases, we can apply lessons learnt from the past while
> | > looking foward to the future.
> |
> | One of those lessons *is* consistency.
>
> Where would you draw the line between 'consistency with known broken
> defaults' and 'willful ignorance of improvement opportunities'?

/Very/ close to consistency.
Seriously: What help is it if the defaults are right in
some cases and wrong in others? How long, do you think,
it will take newbies to remember the cases?
Also teaching, I find "remember, defaults always differ
from what you need to do" can only be superseded by
"they're always right". Everything in between is worse.

> [...]

Schobi

Gabriel Dos Reis

unread,
Jul 9, 2009, 1:54:22 PM7/9/09
to
Hendrik Schober <spam...@gmx.de> writes:

| Gabriel Dos Reis wrote:
| > "Nevin :-] Liber" <ne...@eviloverlord.com> writes:
| >
| > | In article <873a9bx...@gauss.cs.tamu.edu>,
| > | Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| > |
| > | > | The default was chosen about 25 years ago, and that decision
| > | > | can't, practically speaking, be undone.
| > | >
| > | > However, in many cases, we can apply lessons learnt from the past while
| > | > looking foward to the future.
| > |
| > | One of those lessons *is* consistency.
| >
| > Where would you draw the line between 'consistency with known broken
| > defaults' and 'willful ignorance of improvement opportunities'?
|
| /Very/ close to consistency.

I'm afraid that terse answer does not illuminate much as to what the
answer is.

| Seriously: What help is it if the defaults are right in
| some cases and wrong in others? How long, do you think,
| it will take newbies to remember the cases?
| Also teaching, I find "remember, defaults always differ
| from what you need to do" can only be superseded by
| "they're always right". Everything in between is worse.

If the issue is how to teach programmers how to *solve problems* with
C++, I'm doubtful of the effectiveness of teaching language
technicalities, as opposed to programming techniques and their
effective expressions in C++.

Don't get me wrong, I perfectly appreciate the sale value potential of a
catchy phrase like "in C++ all defaults are wrong" in a book that
focuses on language technicalities as opposed to problem solving.
I'm just unconvinced that the language should be evolved with the goal
to keep that sale value potential high. And I also appreciate that
there are other views.

Hendrik Schober

unread,
Jul 11, 2009, 2:02:52 AM7/11/09
to
Gabriel Dos Reis wrote:
> Hendrik Schober <spam...@gmx.de> writes:
>
> | Gabriel Dos Reis wrote:
> | > "Nevin :-] Liber" <ne...@eviloverlord.com> writes:
> | >
> | > | In article <873a9bx...@gauss.cs.tamu.edu>,
> | > | Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> | > |
> | > | > | The default was chosen about 25 years ago, and that decision
> | > | > | can't, practically speaking, be undone.
> | > | >
> | > | > However, in many cases, we can apply lessons learnt from the past while
> | > | > looking foward to the future.
> | > |
> | > | One of those lessons *is* consistency.
> | >
> | > Where would you draw the line between 'consistency with known broken
> | > defaults' and 'willful ignorance of improvement opportunities'?
> |
> | /Very/ close to consistency.
>
> I'm afraid that terse answer does not illuminate much as to what the
> answer is.

As I said below: IMO consistency is much more important to
cling to.

> | Seriously: What help is it if the defaults are right in
> | some cases and wrong in others? How long, do you think,
> | it will take newbies to remember the cases?
> | Also teaching, I find "remember, defaults always differ
> | from what you need to do" can only be superseded by
> | "they're always right". Everything in between is worse.
>
> If the issue is how to teach programmers how to *solve problems* with
> C++, I'm doubtful of the effectiveness of teaching language
> technicalities, as opposed to programming techniques and their
> effective expressions in C++.
>
> Don't get me wrong, I perfectly appreciate the sale value potential of a
> catchy phrase like "in C++ all defaults are wrong" in a book that
> focuses on language technicalities as opposed to problem solving.
> I'm just unconvinced that the language should be evolved with the goal
> to keep that sale value potential high. And I also appreciate that
> there are other views.

<shrug>

I believe Scott has shown very well that a few dozen rules
of thumb can go a long way towards helping people in their
daily work.

FTR: my course is based on Accelerated C++. (Well, that was
about 10 years ago, it's quite different now. But it follows
the same principle.) I suppose this falls into the "solve
problems" camp?
Nevertheless, with Java as the students' only prior language
and with only 20h of lecture plus 20h of lab work to pass a
required C++ course (along 120h of other stuff to understand
and memorize), going from "Hello, C++!" to TMP, turned out to
be a lot less bumpy when accompanied by few rules of thumb.

Schobi

Gabriel Dos Reis

unread,
Jul 12, 2009, 4:19:15 PM7/12/09
to
Hendrik Schober <spam...@gmx.de> writes:


[...]

| > If the issue is how to teach programmers how to *solve problems* with
| > C++, I'm doubtful of the effectiveness of teaching language
| > technicalities, as opposed to programming techniques and their
| > effective expressions in C++.
| >
| > Don't get me wrong, I perfectly appreciate the sale value potential of a
| > catchy phrase like "in C++ all defaults are wrong" in a book that
| > focuses on language technicalities as opposed to problem solving.
| > I'm just unconvinced that the language should be evolved with the goal
| > to keep that sale value potential high. And I also appreciate that
| > there are other views.
|
| <shrug>
|
| I believe Scott has shown very well that a few dozen rules
| of thumb can go a long way towards helping people in their
| daily work.

I emphatically agree that sure a few rules of thumb about
*problem solving in C++* can be a tremedous help for C++ programmers in
their daily work. I do not believe the rules of thumb have to be
about language technicalities.

| FTR: my course is based on Accelerated C++. (Well, that was
| about 10 years ago, it's quite different now. But it follows
| the same principle.) I suppose this falls into the "solve
| problems" camp?

Yup, definitely.

0 new messages