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

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.

07-Sep-2013 21:00, Walter Bright пишет:
> 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

7. Outlined member function return types, parameter types, and function bodies have private access to the module where the aggregate is declared.

I understand why you may want this hack but it starts to smells real bad. Not only we haven't fixed bugs in our module system yet we introduce another kludge into it to support the C++ header + unknown set of files with implementations. Another twist in visibility/accessiblity lookup rules. I expect another wave of bugs regarding @safe/pure/etc. silently accepted for outlined functions and so on.

Now you can't know if a module implements all of stuff it declares or not. Or where it is implemented at all. I would rather restrict this feature w.r.t. where outlined methods can be defined - e.g. same module or in the same sub-package.

Accessibility rules should stay the same as they are now. In that setting if one wants to split methods across multiple file - fine, just declare them 'package' and put implementations deeper down the package tree.

TL;DR: DROP point 7, and describe how to use 'package' to split implementation across multiple files.

-- 
Dmitry Olshansky

On 7 September 2013 18:28, Jos van Uden <usenet@fwend.com> 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.

There's no problem here then!


Only two points I'd add to that list are that outlined member
functions declared in external modules:
- Will error if the aggregate or member declaration is not found (eg:
member doesn't exist in aggregate or external module is not imported).
- Are mangled as if from the module where the aggregate member is declared.

Just clarifies some implementation detail.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Saturday, 7 September 2013 at 17:28:42 UTC, Jos van Uden wrote:
> and you'll need a decent editor

Or just run dmd -H over it.

07-Sep-2013 22:01, Dmitry Olshansky пишет:
> 07-Sep-2013 21:00, Walter Bright пишет:
>> 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
>

Not to mention poor motivation. A huge paragraph that basically states that some folks prefer IDEs to automatically fixup *this* kind of stuff and not *that* kind of stuff.

I could understand this feature can be very convenient in e.g. DDMD that is being converted from C++. Then this and other examples should be provided.

-- 
Dmitry Olshansky

On Saturday, 7 September 2013 at 17:28:42 UTC, 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.

No pun intended, but having it as  _mandatory_ would be a little to much for people like me that don't like this proposal at all.

- Paolo Invernizzi

On Saturday, 7 September 2013 at 17:28:42 UTC, 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.

So the problem is that you need a *basic* editor to make other people's code look like the way you like ?

I'd say this is awesome, and most of the time, you won't achieve that. Don't try to impose your religion to the world.

On 09/07/2013 07:00 PM, 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

> Rationale:

I don't think that the official rationale should include 'readability', giving clear preference to one declaration style over the other.

> Semantics:

First of all, the DIP should address the following additional points:
- CTFE (under which circumstances is an outlined member function CTFE-able?)
- UDA's
- DDOC
- Auto return functions


> 1. Only member functions of aggregates at module scope can be outlined.

Why module scope? Why just member functions?


> 2. Types, parameter types, and pure/const/immutable/shared/nothrow attributes must match. This is necessary as they affect overloading and so are needed for correct selection of which declaration is being outlined.

Why would nothrow/pure affect overloading but @safe/static not?


> 3. Parameter names need not match.

OK. (But maybe it is better to require them to match if given in both places.)


> 4. If there is a default parameter value, it may only appear in the member function declaration.

Probably this is not too bad, but can't you just require the AST to match?


> 5. @safe/@trusted/@system, private/package/public/export access, linkage and storage classes are as set in the declaration, overriding any in effect for the definition.

Isn't the overriding just confusing for no reason?


> 6. Template member functions may not be outlined.

(This is included in point 1.)


> 7. Outlined member function return types, parameter types, and function bodies have private access to the module where the aggregate is declared.

The function names themselves are missing, and maybe you want the type-declaring module to have access to its private function bodies as well if it imports the implementing module. In any case, this is rather ugly. Why not use 'package' for this purpose and keep visibility rather simple? [1]



([1] Well, IMO 'protected' is quite hard to implement in a non-restrictive way in presence of compile-time reflection.)

> 3. Parameter names need not match.

I think we should be conservative and require that parameter names match. This will ensure that code will not break in the future if named parameter functionality is added to the language at some point.