new DIP47: Outlining member functions of aggregates

Jonathan M Davis jmdavisProg at gmx.com
Mon Sep 9 12:30:00 PDT 2013


On Monday, September 09, 2013 15:51:11 Joseph Rushton Wakeling wrote:
> On 09/09/13 15:12, Daniel Murphy wrote:
> > "Jacob Carlborg" <doob at me.com> wrote in message
> > news:l0jrm7$3199$1 at digitalmars.com...
> > 
> >> So what's wrong with this approach, that's already working today:
> >> 
> >> class Foo
> >> {
> >> 
> >> void foo ();
> >> 
> >> void foo ()
> >> {
> >> 
> >> }
> >> 
> >> }
> >> 
> >> void main ()
> >> {
> >> 
> >> auto foo = new Foo;
> >> foo.foo();
> >> 
> >> }
> >> 
> >> BTW, this feature was implemented because you asked for it.
> >> 
> >> --
> >> /Jacob Carlborg
> > 
> > Whoa, I didn't think of applying that to member functions. This seems
> > like
> > the answer. Put your variables and function prototypes at the top of your
> > class. Done.
> 
> Problem -- what about:
> 
> class Foo
> {
> // Declarations
> void foo();
> int bar(double n);
> 
> // Definitions
> void foo() { .... }
> int bar(double n) { ....}
> 
> // Whoops! Forgot to include this one in the
> // declarations list, but it's still accepted
> // as part of the class
> void goo() { ... }
> }
> 
> A well-defined rule for separating out declarations and definitions would
> check for that and throw a compile error.

Walter's proposal would be no different on that count. All that the DIP is 
proposing is a way to define a member function outside of a class. That 
requires that it already be declared in the class, but it doesn't make it so 
that you can't define other functions directly in the class.

- Jonathan M Davis


More information about the Digitalmars-d mailing list