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