On Thursday, 4 August 2016 at 11:41:00 UTC, Jacob Carlborg wrote:
> That works for me [1]. It was reported by Manu and fixed in 2012 [2].

I did some more experimenting, and it turns out that the problem is when the declaration and definition have different linkage. Being C++ functions means that all the functions are declared with extern( C++ ), but the mixin generates essentially extern( D ) functions.

And a bit more prodding and poking, and I found some problems with UDAs - specifically, adding them in the declaration but not having them in the definition. We use UDAs extensively to mark up functions for binding. Depending on when my function collector template instantiates at compile time determines whether I can see the UDAs or not.

So that's technically a bug. But. Before I go running off to the Bugzilla Walter made. Should a user declaring and then later defining a function be forced to 100% replicate that function definition before defining it? If yes, then the compiler needs to error. If no, then there'll need to be some rules made up for it because I can already see how that will be open to abuse.

On Friday, 5 August 2016 at 08:15:37 UTC, Ethan Watson wrote:
> So that's technically a bug. But. Before I go running off to the Bugzilla Walter made. Should a user declaring and then later defining a function be forced to 100% replicate that function definition before defining it? If yes, then the compiler needs to error. If no, then there'll need to be some rules made up for it because I can already see how that will be open to abuse.

i think that actual declaration should match in signature *only*; linkage and UDAs should be taken from prototype declaration. some rationale: this feature is useful mostly for binding generators (the only times i've seen it requested were for binding generators! ;-), so let's make programmer's lives easier here. checking for actual arg and return types is ok (as D doesn't have `()` syntax for "any args", we can't do "wildcard matching"), but there is absolutely no need to repeat other information.

let's hope that other people will agree, or the feature will stay barely useful, as it is now. ;-)

On Friday, 5 August 2016 at 08:40:04 UTC, ketmar wrote:
p.s. the only "gotcha" i see is if prototyp declaration is found *after* the actual function was declared. as D code should not depend of declaration order, this should be either error, or (better!) use prototype to "fix" previous definition (possibly with warning).

On 5 August 2016 at 03:33, Seb via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 4 August 2016 at 12:44:49 UTC, Manu wrote:
>>
>> On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> [...]
>>
>>
>> Bingo! But it's much deeper than that. ref is a disaster. Use it to
>> any real extent; in particular, binding (or fabricating bindings) to
>> extern(C++) code, and you will see just how fast it breaks down in the
>> most horrific of ways (almost always resulting in text mixin). I would
>> fork D just to fix ref!
>
>
> I might sound stupid, but there is a better way than forking:
>
> 1) Work out a _good_ D improvement proposal and submit it for review to
> https://github.com/dlang/DIPs (exact process is explained over there)
> 2) Once accepted, send a PR

Solution is trivial; ref is part of the type. Of course this will break a ton of code, and it's strongly resisted. It'll never happen
>_<

On 8/5/16 6:17 AM, Manu via Digitalmars-d wrote:
> On 5 August 2016 at 03:33, Seb via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 4 August 2016 at 12:44:49 UTC, Manu wrote:
>>>
>>> On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> [...]
>>>
>>>
>>> Bingo! But it's much deeper than that. ref is a disaster. Use it to
>>> any real extent; in particular, binding (or fabricating bindings) to
>>> extern(C++) code, and you will see just how fast it breaks down in the
>>> most horrific of ways (almost always resulting in text mixin). I would
>>> fork D just to fix ref!
>>
>>
>> I might sound stupid, but there is a better way than forking:
>>
>> 1) Work out a _good_ D improvement proposal and submit it for review to
>> https://github.com/dlang/DIPs (exact process is explained over there)
>> 2) Once accepted, send a PR
>
> Solution is trivial; ref is part of the type. Of course this will
> break a ton of code, and it's strongly resisted. It'll never happen
>> _<

Another solution is to make a Ref smart pointer type. But there isn't enough support from the language yet.

-Steve