So what I usually say is that Rust has principled overloading, as opposed to the ad-hoc overloading that's common elsewhere. And that's important both for how Rust does generics as well as for how it does type inference.
So that could have already been init_mouse_event((more, ..., here))
with a trait -- as you mention -- but notably it wasn't. Have you investigated why they made that choice? What is it about the super-long-name approach that they liked better? The "two more parens" approach is obviously less caller-typing-impact than the long name, so they must have been optimizing for something else.
I'll note that the example on the MDN page is not something I'd consider good in any language:
evt.initMouseEvent("click", true, true, window, 0, 0, 0, 80, 20, false, false, false, false, 0, null);
(I've never seen a function with six boolean parameters that I like.) And they seem to agree, since the method is deprecated in favor of the much simpler MouseEvent
constructor.
That one takes only two parameters, the required type one and an options dictionary. Which could translate into rust excellently, with the call potentially looking something like this:
MouseEvent::new(
event_name,
s! {
clientX = 100,
altKey = true,
})
(Using the macro from Short enum variant syntax in some cases - #9 by scottmcm until Esteban's struct defaults RFC happens.)
And it looks like, in the mean time, they've made a builder for it MouseEventInit in web_sys - Rust so it can be ergonomically constructed.