Thread overview
Multiple functions, same signature
Jul 11
Seb
July 11
I was surprised to find out today that this compiles:

void foo() {}
void foo() {}
void main() {}

Is it a bug, or just a weird design decision? "alphaglosined" on IRC seemed to think it was a regression. Please confirm, so that I can file a bug, or understand the design decision rationale.
July 11
On Wednesday, 11 July 2018 at 15:58:05 UTC, Luís Marques wrote:
> I was surprised to find out today that this compiles:
>
> void foo() {}
> void foo() {}
> void main() {}
>
> Is it a bug, or just a weird design decision? "alphaglosined" on IRC seemed to think it was a regression. Please confirm, so that I can file a bug, or understand the design decision rationale.

Definitely a change, but it always compiled, it just used to fail to link

https://run.dlang.io/is/b0JxD9
July 12
On 12/07/2018 3:58 AM, Luís Marques wrote:
> I was surprised to find out today that this compiles:
> 
> void foo() {}
> void foo() {}
> void main() {}
> 
> Is it a bug, or just a weird design decision? "alphaglosined" on IRC seemed to think it was a regression. Please confirm, so that I can file a bug, or understand the design decision rationale.

The reason I think that it is a regression is because of [0].

Either the change log didn't include some changes, environment/linker or its a regression IMHO.

```
Up to      2.071.2: Failure with output:
-----
onlineapp.o: In function `_D9onlineapp3fooFiZv':
/sandbox/onlineapp.d:2: multiple definition of `_D9onlineapp3fooFiZv'
onlineapp.o:onlineapp.d:(.text._D9onlineapp3fooFiZv+0x0): first defined here
collect2: error: ld returned 1 exit status
--- errorlevel 1
-----

2.072.2 to 2.074.1: Failure with output:
-----
onlineapp.o: In function `_D9onlineapp3fooFiZv':
/sandbox/onlineapp.d:2: multiple definition of `_D9onlineapp3fooFiZv'
onlineapp.o:onlineapp.d:(.text._D9onlineapp3fooFiZv+0x0): first defined here
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
-----

Since      2.075.1: Success and no output
```


[0] https://run.dlang.io/is/AGuM6P
July 11
On Wednesday, 11 July 2018 at 16:01:48 UTC, John Colvin wrote:
> On Wednesday, 11 July 2018 at 15:58:05 UTC, Luís Marques wrote:
> Definitely a change, but it always compiled, it just used to fail to link

Do you know why the frontend doesn't complain about a redefinition, like C++ does?
July 11
On 2018-07-11 17:58, Luís Marques wrote:
> I was surprised to find out today that this compiles:
> 
> void foo() {}
> void foo() {}
> void main() {}
> 
> Is it a bug, or just a weird design decision? "alphaglosined" on IRC seemed to think it was a regression. Please confirm, so that I can file a bug, or understand the design decision rationale.

You'll get an error if you call "foo".

-- 
/Jacob Carlborg
July 11
On Wednesday, 11 July 2018 at 16:21:26 UTC, Jacob Carlborg wrote:
> You'll get an error if you call "foo".

I understand that. Still seems like something that the frontend should detect, unless there's a good use case for multiple (re)definitions. If I had to guess, it's probably to support generic code which may have the same or different type modifiers applied, possibly resulting in a collision.

In my specific case, due to the functions being manipulated by generic code, it led to a harder to diagnose bug, since the functions weren't called directly (or at all, of course). Instead, the openmethods library builds a list of dispatch targets, but it didn't detect at compile-time that the targets were redundant, which led to a *runtime* error, and a harder to diagnose situation. openmethods.d could be changed to deal with that, but it seems like the frontend would be the ideal place to check it, unless D should really support redundant functions.
July 11
On Wednesday, 11 July 2018 at 15:58:05 UTC, Luís Marques wrote:
> I was surprised to find out today that this compiles:
>
> void foo() {}
> void foo() {}
> void main() {}
>
> Is it a bug, or just a weird design decision? "alphaglosined" on IRC seemed to think it was a regression. Please confirm, so that I can file a bug, or understand the design decision rationale.

This will be deprecated soon: https://github.com/dlang/dmd/pull/8429