https://issues.dlang.org/show_bug.cgi?id=22021

moonlightsentinel@disroot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |moonlightsentinel@disroot.o
                   |                            |rg
           Severity|normal                      |enhancement

--

https://issues.dlang.org/show_bug.cgi?id=22021

kinke <kinke@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke <kinke@gmx.net> ---
I'm not sure this should work - `extern(<lang>)` doesn't affect the mangling of
nested functions either, only ABI/calling convention. The reason is simple,
nested functions are D only, and the D mangling makes sure there are no
duplicates/conflicts (as it includes the parent function(s)).

The IMO more intuitive workaround is a freestanding function. Exposing a nested D function for consumption from C[++] is probably not very common; I guess the main usage would be consuming an external function from D, and declaring it as nested function in D for locality.

--

https://issues.dlang.org/show_bug.cgi?id=22021

--- Comment #2 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to kinke from comment #1)
> I'm not sure this should work - `extern(<lang>)` doesn't affect the mangling
> of nested functions either, only ABI/calling convention. The reason is
> simple, nested functions are D only, and the D mangling makes sure there are
> no duplicates/conflicts (as it includes the parent function(s)).
> 

I needed that when I was trying to implement a poor man's decorator in the least ugly way:

mixin template ISR(int number, alias impl) {
        static struct Impl {
            extern(C) static
            pragma(mangle, "__vector_" ~ number.stringof)
            @signal @used /* @externally_visible */ void isr() {
                impl();
            }
        }
    }

    /// ditto
    mixin template ISR() {
        enum dummy = 0;
        alias impl = __traits(parent, dummy);
        enum number = mixin(__traits(identifier, impl), "_vect");
        mixin ISR!(number, impl);
    }

@always_inline void USART_UDRE() {
    mixin ISR; // magic
    ...
}


> The IMO more intuitive workaround is a freestanding function. Exposing a nested D function for consumption from C[++] is probably not very common; I guess the main usage would be consuming an external function from D, and declaring it as nested function in D for locality.

Nested functions are conceptually very similar to member functions. It is a matter of good taste to try and make them consistent.

--

https://issues.dlang.org/show_bug.cgi?id=22021

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=22021

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |b2.temp@gmx.com
         Resolution|---                         |FIXED

--- Comment #3 from Basile-z <b2.temp@gmx.com> ---
fixed in https://github.com/dlang/dmd/pull/15582

--