What are the prominent downsides of the D programming language?

[Arafel]

On 30/9/20 15:37, Paulo Pinto wrote:
> 
> interface Gun { void fire(); }
> interface Rocket { void fire(); }
> 
> class Weapon : Gun, Rocket { void fire() {} }
> 
> void protectMyself(Gun g) {
>    g.fire(); // what did I actually do here?
> }
> 
> void defence(Weapon w) {
>    protectMyself(w);
> }
> 
> The name might be merged, but semantics aren't the same and sometimes 
> the unexpected happens, that is why Eiffel and .NET languages approach 
> to explicitly state the interface implementations are much better.

I would say that this design, at least in the example you proposed, is a 
bit backwards? I think the following looks better:

```
interface Weapon { void fire(); }

class Gun : Weapon { void fire() {} }
class Rocket : Weapon { void fire() {} }
```

This matches much more the is-a paradigm: a gun is a weapon, a rocket is 
a weapon, but a weapon is not both a rocket and a gun (well, some weapon 
might bit, but that most likely would be composition, i.e. a weapon 
would consist-of a gun and a rocket).

That said, this of course doesn't mean that there are cases where a 
function with the same name might be defined in two interfaces with 
different semantics:

```
interface I1 {
     int fun () out (r; r < 0);
}

interface I2 {
     int fun () out (r; r > 0);
}

class C : I1,I2 {
     int fun () {return /* ??? */;}
}
```

Of course, the fact that functions with the same name have different 
usage is also a bit suspicious, because interfaces should be orthogonal 
to each other, so I'm not too unhappy that it makes you think twice 
about it.

That's also why I don't care too much about the extra verbosity that 
Java promotes (in the method names), it makes this much less likely.

A.