C is Brittle D is Plastic

[Timon Gehr]

On 3/25/26 03:32, Walter Bright wrote:
> On 3/24/2026 12:23 PM, user1234 wrote:
>> https://www.boxyuwu.blog/posts/an-incoherent-rust/
> 
> If I understand this correctly, D has solved this problem:
> ```d
> import a;   // exports 'x'
> import b;   // exports 'x'
> 
> int z = x; // error, multiple definition of 'x'
> ```
> The resolution:
> ```d
> import a;   // exports 'x'
> import b;   // exports 'x'
> alias x = b.x;
> 
> int z = x; // b.x is selected
> ```

Then so has Rust:
```rust
#![allow(warnings)]

mod a {
     pub const x : i32 = 2;
}
mod b {
     pub const x : i32 = 3;
}
use a::*;
use b::*;

const z : i32 = x; // error: `x` is ambiguous

fn main(){ print!("{}", z); }
```
The resolution:
```rust
#![allow(warnings)]

mod a {
     pub const x : i32 = 2;
}
mod b {
     pub const x : i32 = 3;
}
use a::*;
use b::*;
use b::x as x;

const z : i32 = x; // b::x is selected

fn main(){ print!("{}", z); } // 3
```

The issue is a bit more fundamental to their traits design than just 
disambiguating names. They don't even have names for implementations of 
traits.

Once you have names, in order to detect mismatches between associated 
types, you need some sort of dependent typing, for example 
path-dependent types. This is because implementations are values, and 
the associated types depend on these values.

Enforcing that there can be only one implementation of a trait for a 
given type gets around this dependency: you can treat the mapping from 
implementation to associated type as just a mapping from the type to the 
associated type given by the unique implementation.