On 08/09/13 15:40, Walter Bright wrote:
> 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.

Here's one. It's one of the things that I don't like about C/C++ as it doubles the work required in code maintenance.  One of the things that I like about D is that forward references aren't required and this seems to me to be introducing a feature that was only ever in C/C++ to make forward references possible (which is why I tolerated it).

In summary, you've gotten rid of the need for this type of duplication so why would you introduce it?

Peter

Am 08.09.2013 07:48, schrieb Iain Buclaw:
> 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
>

im talking about "Parameter names need not match."
so it will become hard to find the same overload of a method if someone else writes int a, int b in declaration and int pa, int pb in implementation - and the only benefit is beeing compatible with c/c++ - that will introduce another point in all D-coding-style guides around the world not to rename parameter in implementation

On Sunday, 8 September 2013 at 04:32:36 UTC, Daniel Murphy wrote:
> "Walter Bright" <newshound2@digitalmars.com> wrote in message
> news:l0fm2o$2uat$1@digitalmars.com...
>> 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 am strongly opposed to this DIP.  I think it brings a little slice of C++
> hell to D.
>
> This change will result in manually-synchronized duplication.  The argument
> that IDEs can deal with this automatically is irrelevant, because they
> currently can't and are unlikely to do so any time soon.
>
> The main motivation for this seems to be that you can't get a clear overview
> of a class from looking at the raw source code.  I propose a much simpler
> solution to this:
>
> ** Introduce compiler-checked (via warnings) class summary documentation. **
>
> This solves the problem - an overview of the class is available in the raw
> source code, and enabling the warning will prevent them from getting out of
> sync.
>
> Let's solve a documentation issue with documentation improvements.

This generated documentation solution seems like the best approach.

On 8 September 2013 07:14, dennis luehring <dl.soluz@gmx.net> wrote:
> Am 08.09.2013 07:48, schrieb Iain Buclaw:
>>
>> 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
>>
>
> im talking about "Parameter names need not match."
> so it will become hard to find the same overload of a method if someone else
> writes int a, int b in declaration and int pa, int pb in implementation -
> and the only benefit is beeing compatible with c/c++ - that will introduce
> another point in all D-coding-style guides around the world not to rename
> parameter in implementation

I was talking about "Parameter names need not match" too... I disagree that mismatched parameter names makes things hard to find, and by way of example, I just search for the function.  I never say "right, I need to find this implementation" and grep for the parameter list in the declaration...

Regards
-- 
Iain Buclaw

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

On 9/7/2013 11:08 PM, Peter Williams wrote:
> In summary, you've gotten rid of the need for this type of duplication so why
> would you introduce it?

I believe that is covered in the "Rationale" section of the dip.

Am 08.09.2013 08:46, schrieb Iain Buclaw:
>> im talking about "Parameter names need not match."
>> so it will become hard to find the same overload of a method if someone else
>> writes int a, int b in declaration and int pa, int pb in implementation -
>> and the only benefit is beeing compatible with c/c++ - that will introduce
>> another point in all D-coding-style guides around the world not to rename
>> parameter in implementation
>
> I was talking about "Parameter names need not match" too... I disagree
> that mismatched parameter names makes things hard to find, and by way
> of example, I just search for the function.  I never say "right, I
> need to find this implementation" and grep for the parameter list in
> the declaration...

i work as a independed refactorig/bug hunter developer on big team (30+ developers) big projects (1Mio LOC+) - i need to do that most of the time - i like D for beeing better refactorable/readable in the long run (years) of projects

different people - different needs

On Sunday, 8 September 2013 at 06:47:14 UTC, Walter Bright wrote:
> On 9/7/2013 11:08 PM, Peter Williams wrote:
>> In summary, you've gotten rid of the need for this type of duplication so why
>> would you introduce it?
>
> I believe that is covered in the "Rationale" section of the dip.

IMHO the rationale of the proposal il pretty weak:

- You can't have a 1:1 correspondence with translated C++ code, so the translation barrier can be lower.
- You can't read _easily_ the code.

The first is not a problem, if it is true that D avoidance of duplication is better than C++ way of doing that stuff (and that's a C++ problem, as Peter suggested).
I would also add that I don't think at all that this is a concrete translation barrier: usually I start copying and pasting the C++ header in the D code, and then filling the methods translating from the cpp part one after another.

The second point is more subtle, as we are talking about an easy _navigation_ in the code in the editor, we are talking about being able to "gain a sense of familiarity" with foreign code?

The former is something that should not impact over the language at all (alas, C++ navigation, back and forth between header and implementation is a mess),

The latter resolved by D with DDOC, which it is perfectible BUT is _today_ a wonderful tool for strangers: the D library section on DLang site is there to prove it. You have at a glance all the definitions, documented and in sync with the last compilation. What is missing from that?

- Paolo Invernizzi

I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword.

On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote:
> I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword.

+1

On Sunday, 8 September 2013 at 09:24:52 UTC, Michael wrote:
> On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote:
>> I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword.
>
> +1

I strongly dislike DIP47, I found many unintended discrepancies in our C code-base at work... precisely because of "lax rules", even cases with wrong linkage as result!

"Parameter names need not match."

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

This forces indexing of source and jump to declaration features in the IDE, the current way is more friendly to simpler text-editors, the problem which DIP47 is trying to solve is anyway solved by IDE:s "Class View" feature etc.

i.e.
For people using IDE:s(class view, or ddoc) nothing changes with DIP47.
For people using plain editors, DIP47 makes it worse.

Even if DIP47 is implemented, I hope this feature is strongly discouraged in the standard library.