Add helpful implicit errors #4823

kitlangton · 2021-03-21T03:54:12Z

ZIO uses many implicit evidence constraints to implement methods on the ZIO trait that only work with particular subtypes. For instance, ZIO#some, which requires that the A type is optional, is defined as:

final def some[B](implicit ev: A <:< Option[B]): ZIO[R, Option[E], B] = ???

This is a very cool technique. The only problem is that the error message requires the user to understand how this technique works, particularly the meaning of the <:< symbol:

[error] /Users/kit/code/example.scala:17:25: Cannot prove that Int <:< Option[B].
[error]   val example = UIO(10).some

This could be clearer. Basically, by making our own versions, we can give more ZIO specific compile errors:

We could make this more specific for particularly difficult to use messages, potentially linking to documentation. Overall, this is basically an extension of the pattern used by the CanFail constraint.

adamgfraser · 2021-03-21T04:55:39Z

core/shared/src/main/scala/zio/IsSubtype.scala

+
+import scala.annotation.implicitNotFound
+
+@implicitNotFound("\nOutput Type Mismatch\n  expected: ${B}\n    actual: ${A}\n\n")


What about something like:

This operator requires that the output type be a subtype of Option[Int] but the actual type String was not a subtype of Option[Int]

I agree 👍 Wasn't sure about the alignment / terseness. How about just the follow, so as not to repeat the expected type?
This operator requires that the output type be a subtype of Option[Int] but the actual type was String.

adamgfraser · 2021-03-21T04:56:34Z

core/shared/src/main/scala/zio/IsSubtype.scala

+    override def apply(a: A): B = subtype(a)
+  }
+
+  implicit def implNothing[B]: HasOutput[Nothing, B] = new HasOutput[Nothing, B] {


Do you need these second instances?

I know, right? Some more Scala weirdness. I needed them for some reason. It couldn't find one for Nothing, which means it didn't trigger the CanFail warning, but instead said gave the implicit error for HasError.

adamgfraser · 2021-03-21T05:01:22Z

core/shared/src/main/scala/zio/IsSubtype.scala

+import scala.annotation.implicitNotFound
+
+@implicitNotFound("\nOutput Type Mismatch\n  expected: ${B}\n    actual: ${A}\n\n")
+sealed abstract class HasOutput[-A, +B] extends (A => B)


I wonder if we want to avoid using the term Has here given its existing definition as another data type? Something like IsSubtypeOutput or IsSubtypeOfOutput might be more descriptive and reads relatively well in infix position. Like implicit ev: A IsSubtypeOfOutput Option[B]. We could simplify if we didn't care about distinguishing the channels but I think that is helpful to indicate to the user where something went wrong.

That crossed my mind—Has is accounted for. I like implicit ev: A IsSubtypeOfOutput Option[B] a lot.

kitlangton · 2021-03-21T05:19:53Z

Updated @adamgfraser, but I left STM and ZStream alone for now, as I'm not sure how completely those files are going to change. Though I suppose most of ZIO will as well :P

adamgfraser · 2021-03-21T05:28:22Z

@kitlangton Looks good! Yes I think we're going to have changes to everything to some extent so can't let that stop us. I think this is probably a good point to get feedback from others though and if we have alignment it will be easy to push to the streams and STM as well.

kitlangton · 2021-03-21T05:30:10Z

Sounds good! I'll poke some people on Monday for feedback :)

iravid

Big like 👍

joroKr21 · 2021-03-21T07:13:21Z

Have you considered using a type alias? @implicitNotFound should work on type aliases

adamgfraser · 2021-03-21T12:22:11Z

@joroKr21 That's interesting! I didn't realize you could do that! Unfortunately it doesn't seem to work on Scala 3.

import scala.annotation.implicitNotFound

@implicitNotFound("${A} is not a subtype of ${B}")
type IsSubtypeOf[-A, +B] = A <:< B

object Example {
  implicitly[String IsSubtypeOf Int]
}

// Cannot prove that String <:< Int.

Maybe the Scala 3 team can resolve that. It would certainly be nice to make the implementation of this lighter weight. I will open an issue.

adamgfraser · 2021-03-21T12:26:28Z

Ah, I think this may be resolved by scala/scala3#11823. I commented to confirm.

kitlangton · 2021-03-21T18:14:07Z

Have you considered using a type alias? @implicitNotFound should work on type aliases

Oh cool. Also had no idea that worked :P
But yeah, it looks like they're leaning towards not supporting this in Scala 3. Maybe we could use zio-prelude's Subtype trick? However, as currently there are only two new types, I don't think its too terrifying a sum of boilerplate 😉.

adamgfraser · 2021-03-21T18:15:49Z

I totally agree. Hopefully they will address in Scala 3 but otherwise this is already pretty minimal and any new type machinery is going to be more heavy weight than what you have here.

kitlangton · 2021-03-21T18:24:56Z

Him, though it looks like there may be some other issues on dotty right now:

[info] compiling 106 Scala sources and 1 Java source to /home/circleci/project/core/jvm/target/scala-3.0.0-RC1/classes ...
[error] -- [E008] Not Found Error: /home/circleci/project/core/shared/src/main/scala/zio/ZIO.scala:934:18 
[error] 934 |    map(result => !result)
[error]     |                  ^^^^^^^
[error]     |                  value unary_! is not a member of A
[error] -- [E008] Not Found Error: /home/circleci/project/core/shared/src/main/scala/zio/ZIO.scala:942:13 
[error] 942 |      a => a.fold[ZIO[R, Option[E], Unit]](ZIO.succeedNow(()))(_ => ZIO.fail(None))
[error]     |           ^^^^^^
[error]     |           value fold is not a member of A

Not sure if that's because of my changes. I'll have to take a look.

It looks like maybe the implicit conversion isn't firing as it does with (implicit ev: A <:< Option[B]). Hrm.

joroKr21 · 2021-03-21T20:33:14Z

But yeah, it looks like they're leaning towards not supporting this in Scala 3.

That's a shame. Having a different class means you can't convert back and forth. You are converting from <:< to your custom type but not the other way around so if I have your type I can't use a function that expects <:<

kitlangton · 2021-03-21T20:37:04Z

That's a shame. Having a different class means you can't convert back and forth. You are converting from <:< to your custom type but not the other way around so if I have your type I can't use a function that expects <:<

Oh, good point! What if I make these type extend <:<?

joroKr21 · 2021-03-21T20:40:51Z

Oh, good point! What if I make these type extend <:<?

You could try, but that sounds like it would cause a circular dependency

kitlangton · 2021-04-28T19:23:54Z

But yeah, it looks like they're leaning towards not supporting this in Scala 3.

That's a shame. Having a different class means you can't convert back and forth. You are converting from <:< to your custom type but not the other way around so if I have your type I can't use a function that expects <:<

I actually don't think this will be a problem, as this will only be used internally, and they can be derived from <:<, so as a user, you should never run into this.

adamgfraser

Let's get this merged!

kitlangton requested a review from iravid as a code owner March 21, 2021 03:54

kitlangton force-pushed the helpful-implicit-errors branch from a8977a3 to 5ccad87 Compare March 21, 2021 04:53

adamgfraser reviewed Mar 21, 2021

View reviewed changes

kitlangton force-pushed the helpful-implicit-errors branch from dc43f98 to 6e8bdaf Compare March 21, 2021 05:30

iravid previously approved these changes Mar 21, 2021

View reviewed changes

kitlangton dismissed iravid’s stale review via 9c3229e March 24, 2021 06:50

kitlangton force-pushed the helpful-implicit-errors branch from 6e8bdaf to 9c3229e Compare March 24, 2021 06:50

kitlangton added 2 commits April 28, 2021 00:04

add helpful implicit errors

cd90977

rename and update error messages

4542c68

kitlangton force-pushed the helpful-implicit-errors branch from 9c3229e to 4542c68 Compare April 28, 2021 07:05

scala 3 compatability

25e6fce

adamgfraser approved these changes May 1, 2021

View reviewed changes

adamgfraser merged commit c996dea into zio:series/2.x May 1, 2021

kitlangton mentioned this pull request May 20, 2021

Implement Accessor trait for simple macro-less accessor methods #5130

Merged

kluen mentioned this pull request Apr 2, 2022

Remove reference to '&&&' operator in Scaladoc #6526

Closed


		import scala.annotation.implicitNotFound

		@implicitNotFound("\nOutput Type Mismatch\n expected: ${B}\n actual: ${A}\n\n")

Uh oh!

Add helpful implicit errors #4823

Add helpful implicit errors #4823

Uh oh!

Conversation

kitlangton commented Mar 21, 2021

Uh oh!

adamgfraser Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

kitlangton Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

adamgfraser Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

adamgfraser Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

kitlangton Mar 21, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamgfraser Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

kitlangton Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

kitlangton commented Mar 21, 2021

Uh oh!

adamgfraser commented Mar 21, 2021

Uh oh!

kitlangton commented Mar 21, 2021

Uh oh!

iravid left a comment

Choose a reason for hiding this comment

Uh oh!

joroKr21 commented Mar 21, 2021

Uh oh!

adamgfraser commented Mar 21, 2021

Uh oh!

adamgfraser commented Mar 21, 2021

Uh oh!

kitlangton commented Mar 21, 2021

Uh oh!

adamgfraser commented Mar 21, 2021

Uh oh!

kitlangton commented Mar 21, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joroKr21 commented Mar 21, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kitlangton commented Mar 21, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joroKr21 commented Mar 21, 2021

Uh oh!

kitlangton commented Apr 28, 2021

Uh oh!

adamgfraser left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kitlangton Mar 21, 2021 •

edited

Loading

kitlangton commented Mar 21, 2021 •

edited

Loading

joroKr21 commented Mar 21, 2021 •

edited

Loading

kitlangton commented Mar 21, 2021 •

edited

Loading