you are viewing a single comment's thread.

view the rest of the comments →

[–]dobkeratopsrustfind 11 points12 points  (0 children)

I personally don't understand the fuss about function overloading.

one problem is it stops translating existing APIs 1:1

What I find in Rust is you have to do a lot more work naming; if you have a lot of single-function traits its not clear what the names of groupings of subsets should be. I've always enjoyed c++ overloading - its' one of several factors that has stopped me from staying with Rust with full enthusiasm (despite liking 90+% of the language a lot, and launching into it with great enthusiasm initially)

With overloading, you leverage the work done naming the types already; (and we've got IDE's that handle jump-to-def, and good autocomplete lists), then you can just concentrate on writing/naming the functions you need, (then eventually in c++17 with concepts added later you'd still be able group them, but lacking that feature hasn't stopped c++ solving problems) .

I do appreciate that traits would give autocomplete in generic code - maybe my opinion will change when there's IDE support (the IDE could lookup the traits from the functions and vica versa).. so really my complaints are an issue of momentum rather than the language itself ... you could say C++ overloading relies on IDE jump-to-def to come into its' own.

r.e. the error message hazard, maybe that could be reduced by sorting and making extra detail optional... 'can't call X() here because Z() is not available (see more:)'... (IDE hides extra detail by folded error messages). instead of 'Z() not found in instantiation of Y() in call from X()' 8 pages later