Deprecate .value extension method from input tasks #2709
Conversation
Calling `.value` method on an input task returns `InputTask[A]`, which is completely unintuitive and often results to a bug. In most cases `.evaluated` should be called, which returns `A` by evaluating the task. Just in case `InputTask[A]` is needed, `toInputTask` method is now provided.
| else if (tpe <:< c.weakTypeOf[Task[T]]) | ||
| InputWrapper.wrapTask[T](c)(ts, pos) | ||
| else if (tpe <:< c.weakTypeOf[InputTask[T]]) | ||
| InputWrapper.wrapInputTask[T](c)(ts, pos) |
There was a problem hiding this comment.
What about the case when tpe <:< c.weakTypeOf[InputTask[T]] is true? Why can it be removed?
There was a problem hiding this comment.
See Note I just added to the description of this issue.
There was a problem hiding this comment.
I think I was wrong on the initial analysis. It doesn't match during .value but it does get used in some other code path. Added it back 7250285 with a better test.
eed3si9n
changed the title
|
Why are we breaking this in 0.13? Why not deprecate with replacement in 0.13 and replace/remove in 1.0. |
|
Because I want to break things when we can during the tech preview (0.13.5 onward). |
|
I thought we want to experiment and preview changes, without breaking backwards compatibility (until 1.0), both binary compatibility and source compatibility I assumed, and this is breaking source compatibility. |
eed3si9n
changed the title
|
@dwijnand Changed to deprecation. |
Calling `.value` method on an input task returns `InputTask[A]`, which is completely unintuitive and often results to a bug. In most cases `.evaluated` should be called, which returns `A` by evaluating the task. Just in case `InputTask[A]` is needed, `toInputTask` method is now provided.
Calling `.value` method on an input task returns `InputTask[A]`, which is completely unintuitive and often results to a bug. In most cases `.evaluated` should be called, which returns `A` by evaluating the task. Just in case `InputTask[A]` is needed, `toInputTask` method is now provided.
inputTaskValue is probably a better name since taskValue exists.
* Remove .value from input tasks. Ref #2709 Calling `.value` method on an input task returns `InputTask[A]`, which is completely unintuitive and often results to a bug. In most cases `.evaluated` should be called, which returns `A` by evaluating the task. Just in case `InputTask[A]` is needed, `toInputTask` method is now provided. * Fixed test * Rename toInputTask to inputTaskValue
Calling `.value` method on an input task returns `InputTask[A]`, which is completely unintuitive and often results to a bug. In most cases `.evaluated` should be called, which returns `A` by evaluating the task. Just in case `InputTask[A]` is needed, `toInputTask` method is now provided.
Calling
.valuemethod on an input task returnsInputTask[A], whichis completely unintuitive and often results to a bug.
In most cases
.evaluatedshould be called, which returnsAbyevaluating the task. Just in case
InputTask[A]is needed,toInputTaskmethod is now provided.note
Implicit for
.valueis onInitialize[T]:For instance, in case of
Initalize[InputTask[Unit]],TisInputTask[Unit], so we're checkingtpeto conform toInitialize[InputTask[InputTask[Unit]]], which I don't think would ever match. Fixing the semantics of.valueat this juncture is dangerous, so the best we can do is remove it and tell people to use.evaluated./review @dwijnand, @jsuereth, @Duhemm