-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds Show[Stream] #775
Adds Show[Stream] #775
Conversation
Current coverage is
|
Looks great to me! Thanks for ensuring referential transparency. 👍 |
@@ -58,6 +59,11 @@ trait StreamInstances { | |||
override def isEmpty[A](fa: Stream[A]): Boolean = fa.isEmpty | |||
} | |||
|
|||
implicit def streamShow[A: Show]: Show[Stream[A]] = | |||
new Show[Stream[A]] { | |||
def show(fa: Stream[A]): String = if(fa.isEmpty) "Stream()" else s"Stream(${fa.head.show}, ?)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the .show
syntax here will result in an extra allocation for the ShowOps
object, right? In this particular case that probably doesn't matter, but it may be worth having a convention of not using syntax when it comes at an allocation cost in Cats. I don't know. What do people think?
I'm going to go ahead and merge. This is a useful instance and we can always revisit the syntax usage later. |
@ceedubs - sorry for the delay in responding. Thanks for merging! With regard to the use of the I'm just wondering aloud whether it might be better to investigate what might be possible with value classes/simulacrum/machinist to reduce/remove the cost of using syntax here, instead of imposing the convention and fall back to the convention if we can't get the desired results. It would be nice for users of cats not to have to consider this also so it would be valuable in that sense too. |
Adds a
Show
instance forStream
.Of note, unlike
Stream.toString
, this proposed implementation is referentially transparent.A test exists for this property.
I thought about adding some checks in that test to demonstrate that
toString
exhibits behaviour that violates referential transparency, but I thought that would be too brittle to included in this test, as if a future Scala version rectifies this behaviour inStream
, then the test might break, which might not be nice. It is straightforward to add something that shows this however.