logoalt Hacker News

infogulch • today at 8:03 PM • 2 replies • view on HN

I'm curious about polymorphism. Should it be default on for debug builds just to save storage and compile time? How will rust decide whether to enable polymorphism? Will it be possible to provide source-level polymorphism hints to the compiler?


Replies

estebank • today at 8:21 PM

The "hint" you could provide today for polymorphization is to write code like

    fn needs_string_like(x: Into<String>) {
        fn actual_logic(_: String) {}
        actual_logic(x.into())
    }
which is the explicit way of representing the same thing rustc would be doing automatically. The above will create an almost empty `needs_string_like` for each type that it is called with, but a single `actual_logic`. IIRC some optimization passess would completely remove specific instances of `needs_string_like` (like if you call `needs_string_like(String::new())`).
panstromek • today at 9:05 PM

> polymorphism

I assume you ask about polymorphization, which is a term used to refer to a specific optimization mentioned in the blog post.

The base version which Rust wants the most makes sense to enable by default for all builds, because it's purely just removing duplicate work - this is for cases like Vec<u64> and Vec<i64>, where we currently emit code for each one separately, even though it's pretty much the same for both.

More general version will make sense for debug builds or in some special cases, like when optimizing for size. I believe people also want to experiment with it for some interop use cases (and for that, it'd be useful to have source level annotation). I think it's too early to tell how all of this is going to look like, though.