Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

constant Option is not recognised as constant value in inline if #17788

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
rssh opened this issue Jan 11, 2022 · 7 comments
Closed

constant Option is not recognised as constant value in inline if #17788

rssh opened this issue Jan 11, 2022 · 7 comments

Comments

@rssh
Copy link
Contributor

rssh commented Jan 11, 2022

Compiler version

current (Tue Jan 11 08:53:51 EET 2022) master

Minimized code

object Test {

  inline def get: Option[String] = Some("")

  inline def fun: Unit =
    inline if (get.isDefined) then
      println("value = ${get.get}")
    else
      println("value not set")

  fun

}

Output

[info] welcome to sbt 1.5.5 (Homebrew Java 17)
[info] loading global plugins from /Users/rssh/.sbt/1.0/plugins
[info] loading project definition from /Users/rssh/tests/dotty/compileTimeIfOpt/project
[info] loading settings for project root from build.sbt ...
[info] set current project to test (in build file:/Users/rssh/tests/dotty/compileTimeIfOpt/)
[info] Executing in batch mode. For better performance use sbt's shell
[info] compiling 1 Scala source to /Users/rssh/tests/dotty/compileTimeIfOpt/target/scala-3.1.2-RC1-bin-SNAPSHOT/classes ...
[error] -- Error: /Users/rssh/tests/dotty/compileTimeIfOpt/src/main/scala/x/Test.scala:13:2 
[error] 13 |  fun
[error]    |  ^^^
[error]    |Cannot reduce `inline if` because its condition is not a constant value: (Some.apply[String](""):Option[String]).isDefined
[error]    | This location contains code that was inlined from Test.scala:8

Expectation

Should be compiled.

@rssh
Copy link
Contributor Author

rssh commented Jan 11, 2022

inverse to #14245

@rssh
Copy link
Contributor Author

rssh commented Jan 11, 2022

In case of .isDefined is problematic:

object Test {

  inline def get: Option[String] = Some("")

  inline def fun: Unit =
    inline if (get != None) then
      println("value = ${get.get}")
    else
      println("value not set")

  fun

}

result:

[error] -- Error: /Users/rssh/tests/dotty/compileTimeIfOpt/src/main/scala/x/Test.scala:13:2 
[error] 13 |  fun
[error]    |  ^^^
[error]    |Cannot reduce `inline if` because its condition is not a constant value: (Some.apply[String](""):Option[String]).!=(None)

@rssh
Copy link
Contributor Author

rssh commented Jan 11, 2022

Not sure, this is a bug or not ?

@dwijnand
Copy link
Member

Doesn't look like a bug to me. There's no way the compiler can tell that (Some.apply[String](""):Option[String]).!=(None). Even new Some("") != None isn't certain, because equals could be defined to be true there.

@rssh
Copy link
Contributor Author

rssh commented Jan 11, 2022

I'm not against closing this issue, but want to leave a remark just from the loving to argue:

Option has implemented FromExpr, so a compiler can call FromExpr.unapply to receive an object. And == and !=. are parsed specially, because inline if (1 == 2). works. So, it is possible to check the existence of FromExpr in '=='.

On another side, you are right, that this is more a feature request than a bug.

@nicolasstucki
Copy link
Contributor

Any kind of evaluation performed by inlining must be hardcoded in the compiler. The more we make it do, the slower it will become.

On the other hand, with macros, the code is in the library (such as FromExpr ) which can contain arbitrarily complex partial evaluation abstractions which scale with the use cases. These also are executing compiled code which is faster than full AST interpretation.

@dwijnand
Copy link
Member

Option has implemented FromExpr, so a compiler can call FromExpr.unapply to receive an object. And == and !=. are parsed specially, because inline if (1 == 2). works. So, it is possible to check the existence of FromExpr in '=='.

On another side, you are right, that this is more a feature request than a bug.

TIL FromExpr! 😄 Sounds like a plausible feature request to me, so feel free to rehash this as a request in lampepfl/dotty-feature-requests.

@bishabosha bishabosha transferred this issue from scala/scala3 Jan 11, 2022
@bishabosha bishabosha reopened this Jan 11, 2022
@ckipp01 ckipp01 transferred this issue from lampepfl/dotty-feature-requests Jun 5, 2023
@scala scala locked and limited conversation to collaborators Jun 5, 2023
@ckipp01 ckipp01 converted this issue into discussion #17789 Jun 5, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants