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.
