Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Don't autowire no-arg constructors, or make this configurable?

Open
#184 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
scala

Research direction

The issue does not name files, tests, or entry points. Start by locating the compile-time autowiring implementation and existing tests for no-argument constructors, then determine how configuration could be represented at compile time. Done means the intended no-argument behavior and any package inclusion or exclusion rules are specified and covered by tests.

Written by the indexing model from the issue text.

Description

autowire

Citing @mbore:

Actually I'm still not sure if we want to support no parameters constructors.
It may cause difficult to debug mistakes like "forgot to pass filled config", for example:

import cats.effect._
import cats.effect.unsafe.implicits.global

class MutableConfig() {
  var port: Option[Int] = None
  var host: Option[String] = None
}

class Service(cfg: MutableConfig) {
  println(s"[${cfg.host}]:[${cfg.port}]")
}

object Main extends App {

  def loadConfig(): Resource[IO, MutableConfig] = Resource.pure {
    val mc = new MutableConfig()
    mc.host = Some("xyz")
    mc.port = Some(8080)

    mc
  }

  val cfg = loadConfig()

  val service = autowire[Service]()

  service.allocated.unsafeRunSync()._1

}

it works and prints [None]:[None].
I see that it may reduce boilerplate in some cases, but I'm not sure if it's worth to risk.

Something to consider - I think no-arg implementations might be common, but the argument with configuration is also a valid one.

Maybe we could somehow make this configurable - either support no-arg constructors or not? Or better, maybe the configuration could include packages from which we want to autowire, or a blacklist of packages which should never be autowired?

However, it's challenging to provide such configuration at compile-time - I suppose it would need to be somehow available at the type level?

Dominant language
Scala
Stars
1.3k
Forks
77
Avg merge
9m
Merged PRs (30d)
4

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from softwaremill/macwire

All issues in softwaremill/macwire

Similar issues

More Scala issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.