Wouldn't this style be an acceptable compromise instead? with both declaration and definition 100% identical.

struct S
{
  // member function declarations
  static int mfunc1(int a, int b = 5) pure;
  static int mfunc2(int a, int b = 5) pure;
  static int mfunc3(int a, int b = 5) pure;

  // member function definitions
  static int mfunc1(int a, int b = 5) pure
  {
  }
  static int mfunc2(int a, int b = 5) pure
  {
  }
  static int mfunc3(int a, int b = 5) pure
  {
  }
}

On 09/08/2013 06:46 AM, Jonathan M Davis wrote:
> 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.

+1

On Sunday, 8 September 2013 at 10:59:34 UTC, Robert Schadek wrote:
> On 09/08/2013 06:46 AM, Jonathan M Davis wrote:
>> 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.
>
> +1

+1

Also issues mentioned by Manu are easily solvable:

DI files and/or DDOC + remove one level of indentation after class:

---
class Foo
{


void foo()
{
    writeln("hello world");
}


}
---

;)

08-Sep-2013 09:00, Jonathan M Davis пишет:
> 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?
>

And speaking of IDEs, they easily grow a simple feature - press some short-cut and it would display what dmd -H of the current file looks like. No need to bend the language backwards.

> - Jonathan M Davis
>


-- 
Dmitry Olshansky

On 2013-09-07 17:00:05 +0000, Walter Bright <newshound2@digitalmars.com> said:

> 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

About placing the definition in another module, you say that the definition when outlined in another module would have private access to the private members of the module of declaration. Does that mean that the definition has access to the private members of two modules at the same time, the one it is declared in and the one it is defined in? That seems strange to me.

I find it strange that pure/const/immutable/shared/nothrow need to match, yet static does not. Beside this being the way it works in C++ (presumably because static at global scope has another meaning inherited from C), I see no reason for this. In C++ I often find myself wondering whether a function has access to the member variables and I have to find the definition in the header file, which is inconvenient. Static being part of the definition seems to only make sense.

About parameter names, I think it'd be better if they were forced to match. Mismatches are a code smell to me: if you reverse the meaning of two parameters with the same type while refactoring, you must be sure the public interface and the implementation still agree. I guess you could allow the declaration to omit the parameter names in which case the definition could add a name, but don't allow *different* names, it's pointless and it can easily hide a bug.

I think it's fine that default values for parameters don't have to be repeated, but it'd be nice if they *could* because it enables copy-pasting of the declarations. The compiler would of course have to check that both expressions are identical.

I'd like to make a suggestion. If one goal is effectively to allow the implementation of a function to live in a separate file from its declaration, then we already have a mechanism for that: .di files. So I'd like to suggest this: allow a .d file to "import" its corresponding .di file. Then the .d file should only contain the missing definitions for what's declared in the hand-crafted .di file. That'd remove the dubious semantics of making the definition part of another module and would also allow outlining of global functions. And it also matches better the C++ model of header/implementation files.

Also, I'd allow outlining only for this specific case where a .di file is imported by a .d file. This way you know for sure when you see a declaration without the definition in a .di file that this declaration is in the corresponding .d file and not anywhere else, making it easier to hunt it down.

Example:

	// test.di
	module test;

	class A {
		void foo(int a, int b);
	}

	// test.d
	import module test; // import declarations from the .di file

	void A.foo(int a, int b) {
		// member function definition
	}

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 9/8/13, Michel Fortin <michel.fortin@michelf.ca> wrote:
> So I'd like to suggest this: allow a .d file to "import" its corresponding .di file.

This is actually what Andrei proposed as well.

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 absolutely against this DIP.

This proposal is just going back to the hell of header files again. Why on earth would you emulate C/C++ when D was supposed to be designed taking into account lessons learned from them. This is unnecessary complexity added for the sake of a few programmers who can't get out of C++ mode. I think you need to have a good hard think about *why* header files were introduced into those early languages and then consider if that reason is still valid. Personally i don't think it is. Java and C# do just fine without this.

Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work!

If implemented, i will never used this feature and i will never deal with code that uses it either. I choose D *purely* because it didn't have this header file nonsense. If i find in future i start seeing more and more of this style of D code i would just move on to use something else that doesn't have all this extra baggage and work associated with it. Just because Manu brings it up randomly you decide to create a DIP?

In reality this is a documentation issue. Which has already been addressed by DDOC or *.di files. If data exists in one form, and it is needed in another, that's work a computer should do. Not a human! IDE's also give you numerous tools to get class overviews and such. If you are suggesting that you also need these class overviews in code to be viewed on github etc, just use comments. They are as arbitrary and simpler to implement.

Honestly this DIP is going backwards, i was under the impression D was going forwards! I am so disappointed.

On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby wrote:
> This proposal is just going back to the hell of header files again.

It has nothing to do with header files. Or real header file problems.

> Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work!

It is no different from overriding `interface` methods in class. From the code structure point of view, declaration is interface. Implementation is implementation. Keeping those separate may sometimes/often be useful.

That said, I am strongly against permissive rules proposed in this DIP. It should be similar to overriding rules - any smallest difference between to signatures and program stops compiling. Otherwise it is maintenance hell.

P.S. In general I'd love to have feature feature proposed in DIP47  but its importance is very, _very_ low, right now it is probably the least important DIP in the whole list.

08-Sep-2013 16:02, Michel Fortin пишет:
> On 2013-09-07 17:00:05 +0000, Walter Bright <newshound2@digitalmars.com>
> said:
>
>> 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
>
> About placing the definition in another module, you say that the
> definition when outlined in another module would have private access to
> the private members of the module of declaration. Does that mean that
> the definition has access to the private members of two modules at the
> same time, the one it is declared in and the one it is defined in? That
> seems strange to me.

Same here. This was the ugliest point.

[snip]

> I'd like to make a suggestion. If one goal is effectively to allow the
> implementation of a function to live in a separate file from its
> declaration, then we already have a mechanism for that: .di files. So
> I'd like to suggest this: allow a .d file to "import" its corresponding
> .di file. Then the .d file should only contain the missing definitions
> for what's declared in the hand-crafted .di file. That'd remove the
> dubious semantics of making the definition part of another module and
> would also allow outlining of global functions. And it also matches
> better the C++ model of header/implementation files.

> Also, I'd allow outlining only for this specific case where a .di file
> is imported by a .d file. This way you know for sure when you see a
> declaration without the definition in a .di file that this declaration
> is in the corresponding .d file and not anywhere else, making it easier
> to hunt it down.
>
> Example:
>
>      // test.di
>      module test;
>
>      class A {
>          void foo(int a, int b);
>      }
>
>      // test.d
>      import module test; // import declarations from the .di file
>
>      void A.foo(int a, int b) {
>          // member function definition
>      }
>

With this suggestion it finally becomes sane.

-- 
Dmitry Olshansky