On 2013-09-10 10:49, Joseph Rushton Wakeling wrote:

> Can you explain a bit more about how that works?

The "object" module, part of druntime defines a template with the name "RTInfo". That template will be instantiated with each user defined type.

Currently RTInfo doesn't do anything:

template RTInfo(T)
{
    enum RTInfo = cast(void*)0x12345678;
}

https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L575

If you replace that template with something like:

template RTInfo(T)
{
    enum RTInfo = verifyDeclarations!(T);
}

verifyDeclarations would look something like this, in pseudo code:

void* verifyDeclarations (T) ()
{
    static if (is(T == class))
    {
        foreach (member ; methods!(T))
        {
            static if (!hasDefinition!(member))
                static assert (false, "The member '" fullyQualifiedName!(T) ~ "." ~ member.stringof ~ "' doesn't have a definition");
        }
    }

    return null;
}

> As long as it can provide a guarantee that everything declared has a
> definition, and everything defined has a declaration -- and that they
> match! -- then I think this is probably the solution required.
>
> What I mean is -- it needs to ensure that the issue identified in a
> couple of my earlier posts will be flagged and prevented:
> http://forum.dlang.org/post/mailman.1104.1378795749.1719.digitalmars-d@puremagic.com
>
>
> However, I'm suspicious of anything that would require the programmer to
> be "virtuous" and manually ensure that those checks take place, rather
> than the checks simply being a natural part of the compilation process.

The idea is then you build a tool that "compiles" all your files which uses druntime with the above implementation of RTInfo.

-- 
/Jacob Carlborg

Main issue of .di files that make them useless for anything but providing declarations for blobs is that there is absolutely zero compiler control of .d and .di relation. Fixing this either implies providing good control of how .di is generated via compiler flags (and prohibiting manual modifications) or implementing good part of DIP47 restricted to .di/.d combo (all the signature verifications).

Also it does not seem defined in spec how lookup should happen if both .d and .di are present, and, for example, .di has only declaration. Will compiler check .d for possible inlining if it is present?

I think that .di should always contain only declarations and be _always_ auto-generated by compiler with strict 1-to-1 matching signatures. Then .d are also queried if implementation is needed/considered - but those are not mandatory (aside from templates). Blob bindings distributed may then simply have a stripped down version of .d file (similar to what is now generated by dmd -H).

Key point here is  that .di needs _always_ to be there, with hard guarantees that it is in sync with actual code. Add even one more extra step of getting those and it becomes considerably less convenient than C++-like overview.

On 10/09/13 14:12, Jacob Carlborg wrote:
> verifyDeclarations would look something like this, in pseudo code:
>
> void* verifyDeclarations (T) ()
> {
>      static if (is(T == class))
>      {
>          foreach (member ; methods!(T))
>          {
>              static if (!hasDefinition!(member))
>                  static assert (false, "The member '" fullyQualifiedName!(T) ~
> "." ~ member.stringof ~ "' doesn't have a definition");
>          }
>      }
>
>      return null;
> }

But the problem that I identified wasn't the possibility of members that are declared but not defined.  It was the possibility of members that are defined but not included in the top-of-the-class list of separate declarations.  The whole point is that both the author and the recipient of the code should be able to verify at compile-time that the list of declarations is an accurate summary of the class.

I imagine you could define a verifySeparateDeclarations that would indeed enforce that (for every declaration a definition, and for every definition a separate declaration) but that would have its own issues.

On 9/10/13, Jacob Carlborg <doob@me.com> wrote:
> A mixin should not be necessary. RTInfo can be used for that:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L575

The mixin was demonstrated for convenience so you don't have to
manually type in the class name (or use typeof(this)).

On 9/10/13, Dicebot <public@dicebot.lv> wrote:
> Main issue of .di files that make them useless for anything but providing declarations for blobs is that there is absolutely zero compiler control of .d and .di relation.

Yeah, I think we could attempt to provide an alternative to DIP47 by adding a compiler flag that verifies .d implementations match .di declarations. We don't even have to make the .d files explicitly import the .di files like Andrei proposed.

On Tuesday, 10 September 2013 at 13:32:14 UTC, Andrej Mitrovic wrote:
> On 9/10/13, Dicebot <public@dicebot.lv> wrote:
>> Main issue of .di files that make them useless for anything but
>> providing declarations for blobs is that there is absolutely zero
>> compiler control of .d and .di relation.
>
> Yeah, I think we could attempt to provide an alternative to DIP47 by
> adding a compiler flag that verifies .d implementations match .di
> declarations. We don't even have to make the .d files explicitly
> import the .di files like Andrei proposed.

Please, no compiler flags. It should be default behavior. We are speaking about fundamental binary-level application sanity here.

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

I was away and very busy, I have read only part of the answers in this thread.

I don't like this DIP. If this DIP passes I am probably not going to use this feature in my code.

Go and Python show that it's good to minimize the number of trivially different ways to write code in a language. This DIP does the opposite.


> or even in another module.

This is not a good idea.


> "If you rely on tools to make the code _readable_,

In my opinion this DIP makes the code less readable, and makes the code less DRY.


> 3. Parameter names need not match.

This seems bad. What's the rationale for this? (One perhaps acceptable solution is to put no parameter names in the signature inside the class).

Generally I suggest to fix the biggest module system bugs before modifying the design of related features, like the ones discussed in DIP47.

-----------------

Daniel Murphy:

> Let's solve a documentation issue with documentation improvements.

This seems one better solution to the problem.

But I also suggest people here to read and discuss about the post written by Andrei that touches deeper issues. The module system is currently significantly buggy, and it needs a principled design before trying to add DIP47.

-----------------

Manu:

> People make claims like "write better code, split it up better,
> document your code better,

The D compiler could be modified a bit to generate a bare bones documentation even with not even a comment written in the code.

Bye,
bearophile

On Tuesday, 10 September 2013 at 13:49:21 UTC, bearophile wrote:
> Walter Bright:
>
clip
>
>> 3. Parameter names need not match.
>
> This seems bad. What's the rationale for this? (One perhaps acceptable solution is to put no parameter names in the signature inside the class).
>
I am sure there is a good reason for having no parameter names
in a declaration, but to me this doesn't make much sense.
If people want separate declaration/definition so that they can
get an idea of what a class does, then for non-trivial functions
if the variable names are omitted then your more or less have
to look at the definition anyway.

I must admit whenever I come across such declarations in code I
am reading I always find them kind of irritating.

Apart from functions with say variadic parameter lists, is this
really all that useful?


clip

>
> The D compiler could be modified a bit to generate a bare bones documentation even with not even a comment written in the code.
>
> Bye,
> bearophile

I agree on this last point.

Craig Dillabaugh:

> Apart from functions with say variadic parameter lists, is this
> really all that useful?

There are rare situations when you need to add a certain argument to the function signature, but you don't need to use that argument inside the method/function. This happens for example because of code evolution. In such cases not giving a name to the argument is good, you avoid introducing a useless and unused variable name, making the code simpler, safer, and more clear.

Bye,
bearophile

On Tuesday, 10 September 2013 at 14:15:19 UTC, bearophile wrote:
> Craig Dillabaugh:
>
>> Apart from functions with say variadic parameter lists, is this
>> really all that useful?
>
> There are rare situations when you need to add a certain argument to the function signature, but you don't need to use that argument inside the method/function. This happens for example because of code evolution. In such cases not giving a name to the argument is good, you avoid introducing a useless and unused variable name, making the code simpler, safer, and more clear.
>
> Bye,
> bearophile

I think using calling the variable 'dummy' would likely do the
trick in those instances, but this makes sense.