question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Reconsider failing `.value` inside lambda expression

See original GitHub issue

steps

    test in Test := {
      List(1, 2, 3) foreach { x =>
        streams.value.log.info(s"foo $x")
      }
      (test in Test).value
    }

problem

build.sbt:17: error: The evaluation of `streams` inside an anonymous function is prohibited.

Problem: Task invocations inside anonymous functions are evaluated independently of whether the anonymous function is invoked or not.

Solution:
  1. Make `streams` evaluation explicit outside of the function body if you don't care about its evaluation.
  2. Use a dynamic task to evaluate `streams` and pass that value as a parameter to an anonymous function.

        streams.value.log.info(s"foo $x")
        ^
[error] sbt.compiler.EvalException: Type error in expression
[error] Use 'last' for the full log.

expectation

The task does exactly what I want it to do. It should work without warnings or error.

notes

In general, an error (or even a warning) should be displayed when we are 90% certain that the build is doing something against what the user has intended. In this case, I don’t think it is.

Ref https://github.com/lucidsoftware/neo-sbt-scalafmt/pull/11, https://github.com/sbt/sbt/pull/3216/commits/ca3acc4e52668c77a1f2dfa0cc247a45936cf7bd

/cc @jvican

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:6
  • Comments:6 (5 by maintainers)

github_iconTop GitHub Comments

4reactions
dwijnandcommented, Sep 27, 2017

Personally I’d want it to disable all linting, not just for lambdas - also if’s etc:

import sbt.dsl.power
3reactions
jrudolphcommented, Aug 29, 2017

IMO the whole linter should be removed not only for this particular case but for the others as well. In the default case the macro expansion does the right thing of evaluating the task every time. I guess that’s somewhat surprising for new users but it’s a consequence of the system (and the same as before with the manual syntax). In the case where you want the dynamic behavior you can still use the `dynamicTask`` workaround.

Read more comments on GitHub >

github_iconTop Results From Across the Web

I am failing to understand how lambda expressions work in Java
I have no idea what the assignment of r2 to the lambda expression is supposed to mean. How is the entire object of...
Read more >
3.7 Lambda Expressions and Variable Scope - Java - InformIT
There is no single value to capture. The rule is that a lambda expression can only access local variables from an enclosing scope...
Read more >
Functional programming in Java: Lambda reuse and lexical ...
As you'll see, lambda expressions are deceivingly concise, and it's easy to carelessly duplicate them in code. Duplicate code leads to poor- ...
Read more >
Exceptions in Java 8 Lambda Expressions - Baeldung
The use of try-catch solves the problem, but the conciseness of a Lambda Expression is lost and it's no longer a small function...
Read more >
All About Lambda Function in C++(From C++11 to C++20)
Different types of Lambda expression · Generic Lambdas · Variadic generic Lambda · mutable Lambda · Lambda as a function pointer · Higher-order...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found