Thanks to visit codestin.com
Credit goes to github.com

Skip to content

SI-9248 Lint warning when inferring ?F[_] = Any/Nothing #4401

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

Closed
wants to merge 1 commit into from

Conversation

retronym
Copy link
Member

Any and Nothing are kind polymorphic, meaning the following is valid:

def f[F[A]] = 0; f[Any]; f[Nothing]

This commit warns, under -Xlint:infer-any, when we infer such
type appliations.

@scala-jenkins scala-jenkins added this to the 2.11.7 milestone Mar 25, 2015
@retronym
Copy link
Member Author

Review by @adriaanm

foreachWithIndex(targs){ (targ, idx) =>
val tparam = tparams(idx)
if (!tparam.isMonomorphicType && !targ.isHigherKinded)
reporter.warning(argumentPosition(idx), s"type inferrence relied on kind-polymorphic nature of inferred type `$targ` to conform to type parameter ${tparam.defString}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My Webster's says one r in inference. I didn't know you could spell it inferrible. Like enfant inferrible. Thx again for another interesting answer, not to take you for granted.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The typo stemmed from a copy/paste/edit from the neighbouring warning. Just pushed a a Webster's certified version.

Any and Nothing are kind polymorphic, meaning the following is valid:

    def f[F[A]] = 0; f[Any]; f[Nothing]

This commit warns, under -Xlint:infer-any, when we infer such
type appliations.
@som-snytt
Copy link
Contributor

Suggestion at retronym#11

I had an idea to push the warning check into adjustTypeArgs and return extra info in the Result, handling it up the stack where there is better pos info. But that's too many keystrokes for a temporary solution.

@adriaanm
Copy link
Contributor

I think we should defer this. It makes for a great test of how far we could push abide. If someone would like to pick this up, I'd suggest merging the second if (settings.warnInferAny) with the first. Regarding adjustTypeArgs, I'd rather see that one removed -- why do we need to adjust after the fact anyway?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants