-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FAQ for type inference #2924
FAQ for type inference #2924
Conversation
@som-snytt wdyt about the following version? Why couldn't Scala infer the correct type for my code?This is difficult to generalize about, as there could be a variety of causes and possible solutions. Type inference was greatly improved in Scala 3. If you're using Scala 2, you might try your example in Scala 3 to see if it's handled any better. The most common workaround is simply to add an explicit type to your code. Sometimes using multiple parameter lists helps, as per this language tour section. Questions about type inference often involve
These discussions may shed light on other examples as well. |
@BalmungSan this might interest you as well |
If it's called dotty, then why doesn't my dotted expression work?If I'm implying the correct type for my code, then why can't Scala infer it?Are you using "imply" and "infer" correctly? Expectation or AnticipationI see my PR was more of a placeholder. The github states are draft (WIP, drafts cannot be merged) and open green (ready for review), so if you're reviewing, it should be green. I don't know why there isn't a third state for "shared draft" that precedes green. That would mean, even if somebody accidentally grants an accepting review, don't merge it, as we're still mulling. |
Personally, I really like this FAQ addition. My proposal for the title may be: Why couldn't Scala infer the correct type for my dot-chain expression?Additionally, I think providing a concrete example of the suggested solutions would be useful, as well as explaining why that fixes the problem. Like: // Chane this:
List("ab").toSet.head.head
// Into this:
val set = List("ab").toSet
set.head.head
// This works because ...
// Another option is:
List("ab").toSet[String].head.head
// This also works because ... |
I'm consciously choosing not to do this. In general, I seek to keep FAQ entries short and sweet. A brief answer, and then a link or two or three to whatever other sources on the Internet (or on our own documentation site) exist that expound further. |
That was my intended meaning for marking it "draft", yeah. |
Oh right, forgot about that. |
OK I will update with something like Seth's text. I'm having trouble with any title that says "dot". We say "dotted name" or similar for |
ok I updated the section title. toSet or not toSet, that is the questionI'm like, did I spell |
_overviews/FAQ/index.md
Outdated
|
||
Sometimes, using multiple parameter lists helps inference, as explained in [this section of the language tour](https://docs.scala-lang.org/tour/multiple-parameter-lists.html#drive-type-inference). | ||
|
||
For paradigmatic questions about type inference involving `toSet`, see the discussions on [this ticket](https://github.com/scala/bug/issues/7743) and a related [Q&A](https://stackoverflow.com/questions/5544536/in-scala-2-type-inference-fails-on-set-made-with-toset). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall LGTM but I ask for one change: s/paradigmatic/common/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok I accept pitching it to the commons
I neglected to mention that I inlined the links, to make it ASAP (short as preferred). I changed I also changed |
It should say, "If you are here, you should ask BalmungSan". |
Documents scala/bug#7743
The tour still needs tweaking. per #2648