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

Johan Engelen <jbc.engelen@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbc.engelen@gmail.com

--- Comment #1 from Johan Engelen <jbc.engelen@gmail.com> ---
"GetMonitorInfoA" is also overloaded in this way in druntime, https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/winuser.d#L4425-L4428

--

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

Mike Franklin <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=18385

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #2 from Martin Nowak <code@dawg.eu> ---
This was invented as a tool to deprecate callbacks missing those attributes.
There is unfortunately no wildcard to infer function attributes from parameter
(callback) attributes, though this use-case comes up frequently (e.g. in
interface and class methods besides extern(C) methods).

--

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

Adam Wilson <flyboynw@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |flyboynw@gmail.com

--- Comment #3 from Adam Wilson <flyboynw@gmail.com> ---
I still don't understand why this is not treated as an error. It's obviously generating incorrect C ABI's in this case. If it's used to support a specific (or deprecated) path it needs to be deprecated or warning (ugh) so that we can remove the parts that rely on it and get to a conforming state.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=14147

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
A possible solution to this conundrum is to allow two C overloads of the same function name if they are defined in the same scope. They'd be disallowed if they were in different scopes. The latter would most likely be accidental. A possibility would be to disallow it unless the declarations are both @system.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--