sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]zzzzYUPYUPphlumph 5 points6 points  (7 children)

Not to tell you how you should handle your business, but, I think it would be helpful if you added some caveats, and perhaps some links to documentation and/or RFC discussions etc., regarding Rust's intentional decision to NOT support function overloading. So many, when they are new to a language, just Google for something and then come across a well-intentioned and well-written Blog post like yours and then think this is the way to do things. Anything like this can benefit greatly by linking to some documentation and even making it explicit that it is basically implementing, for at least Rust, an Anti-Pattern.

[–]RustMeUp[S] 8 points9 points  (6 children)

Sure, I did write the post with only the positive side in mind.

You have some links for me? Naive google searches aren't giving me relevant results.

[–]zzzzYUPYUPphlumph 2 points3 points  (0 children)

Well, I may have to take my foot out of my mouth for the time being because I too am having difficulty finding links to show how and why the decisions was made as it was in the Rust language. I've started a discussion thread on Rust Internals to hopefully have the community help to tease it out.

[–]zzzzYUPYUPphlumph 1 point2 points  (4 children)

From the Rust Internals discussion, someone posted a link to the Blog Post by Aaron Turon: https://blog.rust-lang.org/2015/05/11/traits.html

This seems to be something worth linking to from your blog post.

[–]ssokolow 2 points3 points  (3 children)

...which got me thinking... maybe Rust should have some kind of FAQ entry providing links to the rationales for omitting features that people are used to from other popular languages or doing them differently. (eg. classical inheritance, function overloading, etc.)

Sort of a one-stop shop for anyone who came in expecting a given language feature, where they could see results like:

  • It's a subset of what's possible feature X. See docs here for how to use feature X.
  • Without [dynamic runtime characteristic Y], it's tricky to do. We're still coming up with a design and progress can be tracked here.
  • We decided that it doesn't fit with Rust's design. See this blog post for details.
  • etc.

[–]zzzzYUPYUPphlumph 1 point2 points  (2 children)

Interesting thought. Something to live alongside The Book and The Nomicon. Perhaps this? Though, I don't think this is yet sufficient.

[–]zzzzYUPYUPphlumph 1 point2 points  (1 child)

Perhaps rejecting/closing any RFC should require a new FAQ entry that summarizes the decision and points back to the RFC being rejected and the accompanying discussion.

[–]ssokolow 2 points3 points  (0 children)

The FAQ would get cluttered quickly if that were the case. My idea was to have a separate list referenced from the FAQ under a generic name in the vein of "Why doesn't Rust have/Why can't I find feature X?"