September 08, 2013
On Saturday, 7 September 2013 at 17:00:08 UTC, 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

It's this post again:

Why do all of the DIPs that change the grammar never detail the changes to the grammar?
September 08, 2013
On Saturday, September 07, 2013 10:00:05 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

I confess that I really don't like this idea. I think that the separation of declarations and definitions is a serious downside of C++ and that it negatively impacts code maintenence. And from the recent discussion on this, it's clear that quite a few people agree with me.

However, at the same time, there are some folks (like Manu) who really prefer to separate the declaration and definitions so that they can just see the signatures for an entire class' functions at once without seeing any definitions. Personally, I don't think that that's a big deal and that it's far better to just use generated documentation for that, but clearly there's not a consensus on that.

If this DIP is implemented, I do not expect to ever use it, and I hope to never have to deal with code that does (which is ultimately the main reason why I think that it would be a problem if this were implemented - eventually, I'll have to deal with code that uses it even though I think that it harms code maintainibility). But at the same time, I don't know that the fact that quite a few of this really don't like this paradigm is enough a reason to deny it to those who seem to think that it's of value.

If I had to vote though, I'd vote against this, because I think that it's a bad paradigm, and I don't want to deal with it.

On an implementation note, I don't think that #5 is strong enough. I think that it should be an outright error if there is a difference between the declaration and definition rather than giving one precedence over the other. I'd also be inclined to argue that #3 should be thrown out and that parameters should be required to match, but it's unfortunately not all that uncommon in C++ for folks to not even give parameters names in their declarations, so requiring that the parameters match is probably too much, much as I think that that they should be required to.

- Jonathan M Davis
September 08, 2013
Am 07.09.2013 19:00, schrieb 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
>


"Parameter names need not match."

please don't do this - that will nearly kill any easy way of finding the implementation, and there is absolutely no reason for differ here - that is too much sort of C/C++ compatible
and i think in the end all styleguides around the world will tell you not to change the name on implementation
September 08, 2013
On Saturday, September 07, 2013 21:30:10 Andrej Mitrovic wrote:
> On 9/7/13, Walter Bright <newshound2@digitalmars.com> wrote:
> > @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.
> They should both match or there should be an error. Don't allow sloppy code to be written like that, people *will* read both the declarations and the definitions (the team or contributors in an open-source project), and any mismatch will only cause confusion.

Agreed. If we're going to do this, let's not allow the possibility of mismatches or it will make the maintenance problems that this DIP introduces even worse (though I'd prefer that we not implement it at all).

- Jonathan M Davis
September 08, 2013
On Saturday, September 07, 2013 10:00:05 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

Actually, for those who really want this sort of thing, why don't they just use .di files? At that point, you're doing basically the same thing that C++ does anyway (which is part of why I hate .di files). What benefit over that do we really get by adding this feature?

- Jonathan M Davis
September 08, 2013
On 9/8/13 1: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

I would restrict it to a single module for the time being.

We can always open it up to other modules later, but we wouldn't be able to restrict it back to a single module, since that would be a breaking change.

L.
September 08, 2013
On Saturday, 7 September 2013 at 17:00:08 UTC, 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

I'm against that.

Reasons:

- Do not change a language without very solid or even urgent need.

- A concise spec (we are going there that, right?) and reliability is way more important than gadgets or "X has that. We need that, too!".

- What for? This approach is anyway not the right one. If this is about readability then ...
... what's the big issue? "I don't like 'class ...{' at the beginning of my source code and a '}' at the end"?
Because that's what it comes down to.

If this is about readability as in "I want to have a quick and comfortable look
at my module or class interface" (which is a reasonable desire and a useful thing) then ...
... the solution is not to change the language but to have a compiler switch to have the compiler generate a client/interface view file. (One might discuss what exactly should should go there)


A+ -R
September 08, 2013
On 9/7/2013 9:46 PM, Jonathan M Davis wrote:
> On an implementation note, I don't think that #5 is strong enough. I think
> that it should be an outright error if there is a difference between the
> declaration and definition rather than giving one precedence over the other.

I'll point out that C++ has equivalent behavior, and it has not resulted in any complaints I've ever heard. When you outline a C++ member function, you do not need to add 'static', 'private', 'virtual', and in fact you cannot add the latter two.
September 08, 2013
On Sep 8, 2013 5:55 AM, "dennis luehring" <dl.soluz@gmx.net> wrote:
>
> Am 07.09.2013 19:00, schrieb 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
>>
>
>
> "Parameter names need not match."
>
> please don't do this - that will nearly kill any easy way of finding the
implementation,

That depends on your coding style and is not necessarily true.  Eg: I put function names at the start of the line.

int
foo_bar ()
{
}

So all global functions are easily grep'able ('^foo_bar').

Same thing is also done with C++ outlined members ('^Class::foo_bar') and I could see myself adopting the same for D aggregate methods too.

Regards
-- 
Iain Buclaw

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


September 08, 2013
On Saturday, 7 September 2013 at 17:00:08 UTC, 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

"Parameter names need not match."

I can't wait to implement a static code analysis rule that yells at people for not having them match.

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

Shouldn't they match?


"@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."

Again. Someone will create a static code analysis tool that warns about this. Why allow it in the language?