Rust 2019 and beyond: limits to some growth

Re:Rust 2019 and beyond: limits to some growth by Thiez on Thursday December 27, 2018 @04:20AM (#18768469)

   > if Rust introduced overloading and default arguments all those who don't know it exists won't have the language made any harder to use, but those that want it can take advantage of it.

The following program might no longer compile if `f` could be overloaded, additional type annotations would be required.

    fn f(n: u8) -> u8 {
        n + 5
    }
    let o = Some(Default::default());
    println!("{:?}", o.map(f));

In general I would expect overloading to make type inference less reliable (not so much with the compiler getting it wrong, but needing more annotations), which users of Rust that do not want overloading would be right to object to.

[ Parent | on HN ]

Re:Rust 2019 and beyond: limits to some growth by zanny on Thursday December 27, 2018 @09:36AM (#18769629)

I don't want to really derail the thread into a discussion on overloading - I was citing it more as an example of a common desire that also introduces a lot of compiler level complexity without really modifying the language syntax - but I imagine any first pass conservative overload implementation would be restrictive enough to let the compile know if theres only one definition of a function. Default would only break if there were 2+ impls of the same signature and would just require a type annotation then.

I'd argue you could not implement overloading without enough support being in place to let the current single signature inference work as it does, which is also probably a good chunk of why its never been really proposed in earnest. Its a hard problem to approach.

[ Parent | on HN ]