Skip to content

-Ycheck-init warning with Some(this) #9795

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
japgolly opened this issue Sep 15, 2020 · 7 comments
Closed

-Ycheck-init warning with Some(this) #9795

japgolly opened this issue Sep 15, 2020 · 7 comments

Comments

@japgolly
Copy link
Contributor

Minimized code

Dotty ver: 0.27.0-RC1

// compile with -source 3.1 -Ycheck-init
class X:
  val some = Some(this)

Output

[warn] -- Warning:
[warn] 4 |  val some = Some(this)
[warn]   |                  ^^^^
[warn]   |Promote the value under initialization to fully-initialized. Calling trace:
[warn]   | -> val some = Some(this)

Expectation

No warning

@liufengyun liufengyun self-assigned this Sep 15, 2020
@liufengyun
Copy link
Contributor

Thanks for the report @japgolly .

Escape of this in the constructor (in this case Some.apply) is rare in practice. I am curious about the actual use case. Could you please elaborate? Thanks.

@japgolly
Copy link
Contributor Author

japgolly commented Sep 15, 2020

It's a micro-optimisation. Consider this example:

final case class Id(value: Long) {
  val some: Some[this.type] =
    Some(this)
}

It might look odd but sometimes I do this for real performance benefits when there's a very-hot loop (eg. graph traversal / calculation) and your application's logic is heavily affected by the presence or lack of a related node's ID. By storing Some(this) on all instances you can avoid allocations during that hot-spot logic. You might find yourself needing an average of, say, 10 instances of Option[Id] per node so avoiding those allocations adds up.

@japgolly
Copy link
Contributor Author

Oh and btw, if it makes a difference, the reason I used this.type instead of just Id is just habit in this case, but very important when there are existential types involved, and/or you're building up value-level proofs.

@liufengyun
Copy link
Contributor

@japgolly Thanks for the detailed explanation. For now, you can use Some(this: @unchecked) to suppress the warning. In the future, we might enhance the checker with type checking to avoid the usage of @unchecked in such cases.

@ValeriePe
Copy link

This issue was picked for the Issue Spree number 16 of May 24th which takes place in a week from now. @liufengyun @gagandeepkalra @anatoliykmetyuk will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

@liufengyun
Copy link
Contributor

The following paper will be helpful to understand the initialization checker: https://dl.acm.org/doi/10.1145/3486610.3486895

@liufengyun
Copy link
Contributor

Fixed by #15307.

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

No branches or pull requests

3 participants