new DIP47: Outlining member functions of aggregates

[H. S. Teoh]

On Sat, Sep 07, 2013 at 07:28:39PM +0200, Jos van Uden wrote:
> On 7-9-2013 19:00, Walter Bright wrote:
> >Outlining of member functions is the practice of placing the
> >declaration of a member function in the struct/class/union, and
> >placing the definition of it at global scope in the module or even in
> >another module.
> >
> >http://wiki.dlang.org/DIP47
> 
> 
> The problem is that it is optional, so when you're reading other
> people's code you'll still have to deal with inline definitions, and
> you'll need a decent editor (doesn't have to be an IDE, even basic
> editors like notepad++ and editpad pro support code folding and
> function lists) to easily read it.

This in itself is a pretty strong argument against this DIP. It
introduces additional cognitive overload (now we have to learn a second
syntax for defining class members), and *still* doesn't help the people
who want this feature in the first place when they have to read others'
code.

Not to mention, this will add additional complexity to the parser, and
probably introduce more bugs related to function attributes -- for
example:

- Should function attributes be repeated verbatim across the in-class
  declaration and the out-of-class definition?  If not, where can they
  be omitted?

- What about attribute inference? What if the definition has attributes
  that conflict with the in-class declaration?

- How will this interact with the current DI generation code?

- How will it affect forward references (which are currently already
  rather wonky in certain areas)?

- What about nested classes? Will they be allowed to have outlining
  member functions too? Where should their member definitions be, and
  what should their syntax be? How will attribute inference work for
  them?

I vote against this DIP. I feel like it's adding a lot of complexity to
the language (and probably many more bugs to the compiler) for only a
small gain. We already have enough wrinkles yet to be ironed out (scope,
shared, auto ref, AA's, inout ambiguities, postblit, tail-const,
emplace, the combinatorial explosion of all the different interactions
between the foregoing, just to name a few), why are we introducing yet
another level of complexity into the mix?


T

-- 
Tech-savvy: euphemism for nerdy.