On 26 September 2012 13:09, deadalnix <deadalnix@gmail.com> wrote:

> Le 26/09/2012 10:14, Manu a écrit :
>
>> On 26 September 2012 02:35, Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>> wrote:
>>
>>     On 09/26/2012 01:29 AM, Timon Gehr wrote:
>>
>>         On 09/25/2012 01:53 PM, Manu wrote:
>>
>>             So I have this recurring pattern, it's really starting to
>>             annoy me.
>>             It stems from the fact that a function prototype and the
>>             definition can
>>             not appear in the same file in D (as it can in C/C++)
>>             Eg,
>>
>>             void func(int x); // <-- declaration of function, informs
>>             type and
>>             associated names, args, ...
>>
>>             //later
>>             void func(int x) // <-- may be generated with magic (and may
>>             use the
>>             prototype declaration for type information as declared by
>>             the prototype
>>             above)
>>             {
>>                 ... do stuff
>>             }
>>
>>             I really need this. Why is it illegal? Is there chance of
>>             having this
>>             supported? What are the problems?
>>             ...
>>
>>
>>         It is illegal because nobody has written code to support it. It
>>         should be possible to support it. I don't think there are any
>>         problems
>>         with the concept.
>>
>>
>>     (The implementation faces some challenges, the following is easy to
>>     get wrong:
>>
>>     module module_;
>>
>>     void foo();
>>
>>     alias foo alias1;
>>     static if(is(typeof(alias1))){
>>          void foo(){}
>>          alias foo alias2;
>>     }
>>
>>     static assert(__traits(isSame, alias1, alias2));
>>     static assert(__traits(allMembers, module_).length == 3); // 2
>>     alias, 1 function definition
>>     )
>>
>>
>> I'm not sure I understand the point being illustrated here. I don't see how the aliases are relevant?
>>
>
> From a compiler perspective, the example above is hell. That was his point.
>
> In other terms, supporting such a feature add complexity to the compiler, and it should come with a sufficient benefice to make sense to implement.
>

I can't imagine why the example above is hell, but I know nothing about the compiler.

I have no idea how the existing bug was implemented, but it needs to be
fixed one way or another.
It sounds fairly trivial to me to promote a prototype to a definition if a
definition is found later in the same module.

On Wednesday, 26 September 2012 at 10:09:14 UTC, deadalnix wrote:
> In other terms, supporting such a feature add complexity to the compiler, and it should come with a sufficient benefice to make sense to implement.

It seems to be just opposite: creating ambiguity between function body and its declaration is a language complexity.

On 2012-09-26 12:19, Manu wrote:

> I can't imagine why the example above is hell, but I know nothing about
> the compiler.
>
> I have no idea how the existing bug was implemented, but it needs to be
> fixed one way or another.
> It sounds fairly trivial to me to promote a prototype to a definition if
> a definition is found later in the same module.

If the definition is found first, just ignore the prototype?

-- 
/Jacob Carlborg

On 26 September 2012 14:21, Jacob Carlborg <doob@me.com> wrote:

> On 2012-09-26 12:19, Manu wrote:
>
>  I can't imagine why the example above is hell, but I know nothing about
>> the compiler.
>>
>> I have no idea how the existing bug was implemented, but it needs to be
>> fixed one way or another.
>> It sounds fairly trivial to me to promote a prototype to a definition if
>> a definition is found later in the same module.
>>
>
> If the definition is found first, just ignore the prototype?


Indeed.

On 25.09.2012 13:53, Manu wrote:> So I have this recurring pattern, it's really starting to annoy me.
> It stems from the fact that a function prototype and the definition can
> not appear in the same file in D (as it can in C/C++)
> Eg,
>
[...]
> I also have numerous more advanced cases of the same problem, and
> becomes even more unsightly when used in structs to emulate dynamic
> linkage to static methods of C++ classes.
>
> The solution is seemingly trivial; allow function prototypes and
> definitions to exist in the same file, like in C/C++.
>

I think this should be allowed, aswell as implementing forward declared enums and structs (IIRC the compiler even has some error messages that suggest that it is intended).

As a workaround, you could put your prototypes into a struct and generate the declarations for the static linking and the stubs for dynamic linking from their declarations and run your magic on the members of "prototypes":

struct prototypes
{
	void fun1(int a, int b);
	void fun2(int a, int b);
}

mixin(magic([__traits(allMembers, prototypes)])


That way you don't put the symbols into the same scope as the prototypes, and you will not add new symbols to the same scope that you are iterating over.

On 26 September 2012 20:28, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
> I think this should be allowed, aswell as implementing forward declared enums and structs (IIRC the compiler even has some error messages that suggest that it is intended).
>
> As a workaround, you could put your prototypes into a struct and generate the declarations for the static linking and the stubs for dynamic linking from their declarations and run your magic on the members of "prototypes":
>
> struct prototypes
> {
>         void fun1(int a, int b);
>         void fun2(int a, int b);
> }
>
> mixin(magic([__traits(**allMembers, prototypes)])
>
>
> That way you don't put the symbols into the same scope as the prototypes, and you will not add new symbols to the same scope that you are iterating over.
>

Good idea! I'll give that a shot.

So it seems like there is fairly general consensus on this then, is there a next step? Should I log a bug? (I think I did log one months ago)