Nested Functions in C++

Nested Functions in C++

[Steven L. Zook]

Are there plans for adding nested function support to C++?

Are there significant obstacles in the way of doing so?

Re: Nested Functions in C++

[Mark Mitchell]

Steven L. Zook wrote:

>Are there plans for adding nested function support to C++?
>  
>
No.

>Are there significant obstacles in the way of doing so?
>  
>
Technically, it's only work.  But, the C++ maintainers (myself included) 
will probably not be keen on accepting such a patch.  We're generally of 
the opinion that adding extensions to C++ is a mistake, unless they go 
through the ISO standardization process first.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: Nested Functions in C++

[Joe Buck]

On Fri, Oct 22, 2004 at 11:35:52AM -0700, Mark Mitchell wrote:
> Steven L. Zook wrote:
> 
> >Are there plans for adding nested function support to C++?
> >  
> >
> No.
> 
> >Are there significant obstacles in the way of doing so?
> >  
> >
> Technically, it's only work.  But, the C++ maintainers (myself included) 
> will probably not be keen on accepting such a patch.  We're generally of 
> the opinion that adding extensions to C++ is a mistake, unless they go 
> through the ISO standardization process first.

I don't think it's necessary for the extensions to have completed the
ISO process all the way to official parts of the language, but at least
they should be serious proposals, with rigorous specifications, that have
been at least partway through the process (written up as proposed
extensions, have been subject to criticism and review from standards
people, etc).  In particular, problematic interaction with other language
features needs to be worked out before the extension is inflicted on
users.

Consider a feature like the new use of "auto", championed by Bjarne
himself.  There appear to be some details that have not yet been worked
out, but maybe the best way to iron out the remaining issues is to have
a trial implementation to play with.

This is the one that lets you write

func (std::multimap<std::string, std::string>& amap, std::string key) {

     auto iter_pair = amap.equal_range(key);
     ...
}

instead of

func (std::multimap<std::string, std::string>& amap, std::string key) {

     std::pair<std::multimap<std::string, std::string>::iterator,
               std::multimap<std::string, std::string>::iterator>
	  iter_pair = amap.equal_range(key);
     ...
}

I want that!  I wanted it years ago.

Re: Nested Functions in C++

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Steven L. Zook wrote:
| 
| >Are there plans for adding nested function support to C++?
| >
| No.
| 
| >Are there significant obstacles in the way of doing so?
| >
| Technically, it's only work.  But, the C++ maintainers (myself
| included) will probably not be keen on accepting such a patch.  We're
| generally of the opinion that adding extensions to C++ is a mistake,
| unless they go through the ISO standardization process first.

Here is my own opinion.
I don't see what is wrong with using member function of local classes
and being explicit about when a reference or a copy of local variable
is needed. I can see why one may have a crying need for it in C; in
C++, the expressive power it provides seems very much quite unnoticeable.

There were lots of new proposals this week, and when something akin to
nested functions/lambdas were mentioned, my impression was that they
weren't the features that would have support from the "main" players.

-- Gaby

Re: Nested Functions in C++

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

[...]

| Consider a feature like the new use of "auto", championed by Bjarne
| himself. 

If things go well, we may have to vote for inclusion in the working
paper in 6 months (the decltype part may have to wait another 6 months). 

| There appear to be some details that have not yet been worked
| out, but maybe the best way to iron out the remaining issues is to have
| a trial implementation to play with.
| 
| This is the one that lets you write
| 
| func (std::multimap<std::string, std::string>& amap, std::string key) {
| 
|      auto iter_pair = amap.equal_range(key);
|      ...
| }
| 
| instead of
| 
| func (std::multimap<std::string, std::string>& amap, std::string key) {
| 
|      std::pair<std::multimap<std::string, std::string>::iterator,
|                std::multimap<std::string, std::string>::iterator>
| 	  iter_pair = amap.equal_range(key);
|      ...
| }
| 
| I want that!  I wanted it years ago.

And it was implemented in Cfront as early as 1983; it was removed, when
some users considered it to be going too far.  Seems like we're back
to the future :-)

-- Gaby

Re: Nested Functions in C++

[Joe Buck]

On Fri, Oct 22, 2004 at 11:50:32PM -0500, Gabriel Dos Reis wrote:
> | [ auto ]
> | I want that!  I wanted it years ago.
> 
> And it was implemented in Cfront as early as 1983; it was removed, when
> some users considered it to be going too far.  Seems like we're back
> to the future :-)

But there were no templates and no STL then, so we didn't have massive
type names to deal with.  It wasn't needed then, it is needed now.

Re: Nested Functions in C++

[Andrew Haley]

Mark Mitchell writes:
 > Steven L. Zook wrote:
 > 
 > >Are there plans for adding nested function support to C++?
 > >  
 > No.
 > 
 > >Are there significant obstacles in the way of doing so?
 > >
 > Technically, it's only work.  But, the C++ maintainers (myself included) 
 > will probably not be keen on accepting such a patch.  We're generally of 
 > the opinion that adding extensions to C++ is a mistake, unless they go 
 > through the ISO standardization process first.

I've always been baffled by this line of reasoning.  The TC is not in
the business of language design AFAIK, and surely they shouldn't be
standardizing features that haven't been implemented by anyone.

So, if we don't implement proposed language extensions people who want
to experiment will probably be forced to use proprietary compilers.

And no, this isn't a call for a free-for-all.  But some extensions are
so useful that we should seriously consider them before the TC has
decided to standardize them.

Andrew.

Re: Nested Functions in C++

[Steven Bosscher]

On Saturday 23 October 2004 13:11, Andrew Haley wrote:
> So, if we don't implement proposed language extensions people who want
> to experiment will probably be forced to use proprietary compilers.

People can still experiment with extensions in private
trees.

> And no, this isn't a call for a free-for-all.  But some extensions are
> so useful that we should seriously consider them before the TC has
> decided to standardize them.

And what if the TC decides to standardize something similar
but not the same?  That means you either accept that your
compiler will not be backward compatible, or you have to
maintain your own non-standard extensions alongside the new,
standardizes language feature.

Gr.
Steven

Re: Nested Functions in C++

[Robert Dewar]

Andrew Haley wrote:
> Mark Mitchell writes:

>  > Technically, it's only work.  But, the C++ maintainers (myself included) 
>  > will probably not be keen on accepting such a patch.  We're generally of 
>  > the opinion that adding extensions to C++ is a mistake, unless they go 
>  > through the ISO standardization process first.
> 
> I've always been baffled by this line of reasoning.  The TC is not in
> the business of language design AFAIK, and surely they shouldn't be
> standardizing features that haven't been implemented by anyone.
> 
> So, if we don't implement proposed language extensions people who want
> to experiment will probably be forced to use proprietary compilers.
> 
> And no, this isn't a call for a free-for-all.  But some extensions are
> so useful that we should seriously consider them before the TC has
> decided to standardize them.

I agree with Andrew here, I don't think it is necessary to wait
for the standardization process to be completed before new features
are implemented. At the same time, I don't think you want to go wild
implementing fun new features.

In the GNAT arena as an example, there are a number of language
proposals for "Ada 2005" which is the new version of the language
expected to be finally approved in 2005. We are actively implementing
features that have been tentatively approved by the first
stage of the process. This means that many of these features
are available today in GNAT and can be used more than a year
before they are officially standardized. People using these
features are certainly warned that things might change before
the final standard (the removal of WITH TYPE was a good example),
but on the other hand, the Ada community can experiment with the
use of these features now, and we think that kind of input will
be very helpful in making sure that the final features that are
approved will be done right. We certainly don't want too much
churning around, so we try to implement only things that we think
are pretty sure to be approved (we participate actively in the
standardization process of course).

Re: Nested Functions in C++

[Andrew Haley]

Steven Bosscher writes:
 > On Saturday 23 October 2004 13:11, Andrew Haley wrote:
 > > So, if we don't implement proposed language extensions people who want
 > > to experiment will probably be forced to use proprietary compilers.
 > 
 > People can still experiment with extensions in private
 > trees.

Yes, but I don't think experimental features should be standardized
without some pretty serious application experience -- and serious
applications tend to be built with real compilers.

 > > And no, this isn't a call for a free-for-all.  But some extensions are
 > > so useful that we should seriously consider them before the TC has
 > > decided to standardize them.
 > 
 > And what if the TC decides to standardize something similar
 > but not the same?  That means you either accept that your
 > compiler will not be backward compatible, or you have to
 > maintain your own non-standard extensions alongside the new,
 > standardizes language feature.

Indeed.  These are serious risks, and must be carefully weighed when
considering language extensions.  But you have to balance risks, and I
believe that the risk of the ISO standardizing a bad language feature
is far greater if that feature has not been much used.

Andrew.

Re: Nested Functions in C++

[Robert Dewar]

Andrew Haley wrote:

> Indeed.  These are serious risks, and must be carefully weighed when
> considering language extensions.  But you have to balance risks, and I
> believe that the risk of the ISO standardizing a bad language feature
> is far greater if that feature has not been much used.
> 
> Andrew.

One point here is that I think any such experimental features
should never be available by default. It should be necessary
to use some special switch or directive.

Re: Nested Functions in C++

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| Andrew Haley wrote:
| 
| > Indeed.  These are serious risks, and must be carefully weighed when
| > considering language extensions.  But you have to balance risks, and I
| > believe that the risk of the ISO standardizing a bad language feature
| > is far greater if that feature has not been much used.
| > Andrew.
| 
| One point here is that I think any such experimental features
| should never be available by default. It should be necessary
| to use some special switch or directive.

While I agree with your statement in general, existing practice
suggest otherwise :-(

-- Gaby

Re: Nested Functions in C++

[Robert Dewar]

Gabriel Dos Reis wrote:
> Robert Dewar <dewar@gnat.com> writes:

> | One point here is that I think any such experimental features
> | should never be available by default. It should be necessary
> | to use some special switch or directive.
> 
> While I agree with your statement in general, existing practice
> suggest otherwise :

Well I know that historically C extensions have been available
by default, but I think that if we consider adding anticipatory
features to g++ before they are standardized, then they should
be under control of a non-default switch.

Re: Nested Functions in C++

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| Gabriel Dos Reis wrote:
| > Robert Dewar <dewar@gnat.com> writes:
| 
| > | One point here is that I think any such experimental features
| > | should never be available by default. It should be necessary
| > | to use some special switch or directive.
| > While I agree with your statement in general, existing practice
| > suggest otherwise :
| 
| Well I know that historically C extensions have been available
| by default, but I think that if we consider adding anticipatory
| features to g++ before they are standardized, then they should
| be under control of a non-default switch.

You don't need to convince me :-)

-- Gaby