At least the end-user won't have to think about the subtlety of "task" vs Def.Initialize[Task[...]] vs Task[...]. I think that's a progress.

This would be like a macro-level hack so you could do scalaVersion := Some("2.12.1") by just unwrapping the Some.

Personally I think this would be just as easily solved with a Def.taskValue, but feel free to overrule and merge.

My real target is the backport to 0.13.14, so we can address both of the issues that came up in 0.13.13 regarding <<= deprecation (this and #1444).

I think instead we should provide Def.taskValue { .. } as a "solution" to the criticism on Def.task { .. }.taskValue. And then add -Ywarn-value-discard by default to the meta-build scalacOptions, like we added -deprecation.

I don't see Def.taskValue { Nil } as an improvement over (Def.task { Nil }).taskValue since you're still introducing additional concept to migrate from <+= without apparent return to the user. Worse, this would add discrepancy with task key. The test for this PR supports:

sourceGenerators in Compile += buildInfo,
sourceGenerators in Compile += Def.task { Nil }

Worse, this would add discrepancy with task key.

What discrepancy? What do you mean?

Worse, this would add discrepancy with task key.

What discrepancy? What do you mean?

In general this is where the rubber meets the road, or (insert impedance mismatch analogy).
We teach people about settings vs tasks, there are keys specific to settings and tasks, but the actual types around "settings" and "tasks" are more complicated.
What we colloquially call "settings" are actually Def.Initialize[A]. Note SettingKey[A] extends KeyedInitialize[A].

Similarly, what we colloquially call "tasks" are Def.Initialize[Task[A]]. TaskKey[A] extends KeyedInitialize[Task[A]]. This is how we are able to maintain the consistent feel of custom tasks Def.task { ... } and built-in task (keys).

My claim is that the build user expects sourceGenerators to also collect reference to "tasks", and that its type is SettingKey[Seq[Task[Seq[File]]]] is not that important. In other words, I should be able to write:

sourceGenerators in Compile += buildInfo

Should you also be able to write crossScalaVersions += scalaVersion? crossScalaVersions collects version strings and scalaVersion is a version string.

Should you also be able to write crossScalaVersions += scalaVersion? crossScalaVersions collects version strings and scalaVersion is a version string.

No, I don't think so. We know crossScalaVersions is SettingKey[Seq[String]] as in a "setting of sequence of String", and scalaVersion a "setting of String". So it's perfectly consistent with Getting Started narrative that it requires .value in:

crossScalaVersions += scalaVersion.value

The tricky bit is that sourceGenerators is SettingKey[Seq[Task[Seq[File]]]], a "setting of sequence of Tasks". I'm trying to smooth out the awkwardness that Task is actually not "task".

Let's be clear, sourceGenerators and resourceGenerators are outliers that expose sbt's underlying Task type. We should either (a) own this complexity and detail/document it more/better or (b) address the complexity. For instance why can't they, instead of be SettingKey[Seq[Task[Seq[File]]]], be TaskKey[Seq[File]]? I don't think we should pick option (c): obscure it, by introducing false Append providers and a macro-level implicit conversion.

If it's accepted that you can't crossScalaVersions += scalaVersion but you must crossScalaVersions += scalaVersion.value, then it's equally accepted that sourceGenerators in Compile += buildInfo doesn't make any sense, and that if you want the underlying value (Seq[File) then you buildInfo.value, and if you want the underlying task then you buildInfo.taskValue.

And if adding an inline task by writing sourceGenerators in Compile += Def.task { .. }.taskValue is too annoying let's add Def.taskValue { .. }.

Or, of course, it's your prerogative to overrule me.

Or, of course, it's your prerogative to overrule me.

I'm fairly sure this magic is the way to go.

For a reference, earlier version of sbt required seq(...) function to put Seq[Setting[_]] in build.sbt. This was worked around by implicit magic in f8d12c5 that unified Seq[Setting[_]] and Setting[_] into SettingsDefinition. We still carry that over today - https://github.com/sbt/util/blob/5306e292900676f69dde458b9a2d7223e3a4c141/internal/util-collection/src/main/scala/sbt/internal/util/Settings.scala#L426-L434

In this case, the implicit conversion from "task" to Task can be considered analogous of eta expansion in Scala. This matches user expectation as we see in these comments sbt/website#306 (comment):

Despite writing many sourceGenerators, it's not clear what this whole Def.task{}.taskValue thingy is about, even after reading this snippet. Why can we not directly += the result of myGenerator?

why have a macro at all, isn't this ideal for an implicit conversion?

A few thoughts:

1. Do implicit conversions kick-in post macro-expansion?
2. This "conversion" can only happen within the context of sbt's macros, you can't generally call Initialize[Task[T]].taskValue, so I don't think you can define the implicit conversion
3. Having it as a macro-level hack at least scopes it to only this codepath, rather than anywhere.

I am doing an implicit conversion. It's just that the RHS requires a macro, so it's stubbed with ???.

One thought: is the failure in CI relevant? I believe it is.

iirc I cancelled the Travis job on merge commit because there was some other thing I needed to verify at the time.