The tests are not passing! Looks like there's an issue with sbt reporting a failed run to jenkins.

So, are we okay deprecating this fine piece of code?

    def inverter(input: Wire, output: Wire): Unit = {
      def invertAction() = {
        val inputSig = input.getSignal;
        afterDelay(InverterDelay) {() => output.setSignal(!inputSig) };
      }
      input addAction invertAction
    }

not sure.. the example doesn't look bad.

i guess the goal is to fix some other examples that are unwanted / trip up users. can we narrow them down more?

I assume addAction takes an argument of type () => Unit. It could use a by-name parameter => Unit instead. Considering that both do pretty much the same and the former already doesn't work with SAMs, I think it makes sense to deprecate it.

Do you mean to deprecate () => Unit generally?

No, I meant eta-expanding to that function type (and others with an empty argument list) :-)

I was referring to stefan's comment above mine - maybe I misunderstood.

We clearly need more threading :-)

No, only eta-expanding these types. I generally use types of the form () => T instead of => T when I want explicit control over when they are evaluated. It's useful to have the type system enforce that.

For me, I would naturally define addAction with an argument type () => Unit. By-name parameters can also be dangerous, recent example: #5157 (comment)

Yes, this is probably one of those cases where you want to be explicit. So you'd have to write:

def inverter(input: Wire, output: Wire): Unit = {
  def invertAction() = {
    val inputSig = input.getSignal;
    afterDelay(InverterDelay) {() => output.setSignal(!inputSig) };
  }
  input.addAction(invertAction _)
}

I think I'd prefer this version:

def inverter(input: Wire, output: Wire): Unit = {
  val invertAction = () => {
    val inputSig = input.getSignal;
    afterDelay(InverterDelay) {() => output.setSignal(!inputSig) };
  }
  input addAction invertAction
}

Both of these should still be allowed, right?

right. that is probably a fair price to pay. didn't we also have recent discussions about deprecating explicit eta-expansion through (invertAction _)?

Thanks for making my question more explicit, Stefan. I would agree the val invertAction more clearly conveys the intent here. Certainly, that one should be allowed. Regarding explicit eta-conversion, I don't remember a discussion on deprecating that one. I would think it's fine to write invertAction _ to mean () => invertAction()?

OK, I read through the ticket and some more history, I agree we should get this deprecation in.

The current patch also warns on explicit eta-expansion:

scala> def f(): Unit = {}
f: ()Unit

scala> f _
<console>:13: warning: Eta-expansion of zero-argument method values is deprecated. Did you intend to write f()?
       f _
       ^
res0: () => Unit = $$Lambda$1718/1023344953@7c29adc8

added distinction between f and f _ in #5327