I like this.But what type should be TypeName? it’s a TypeName | Null or Option[TypeName]?
@sjrd: I like your a: String? definition / clarification, that would be a nice addition to Scala.
Given the feedback in this thread, how about we proceed with a: String? and drop ?.?
(Separately, I wish we could drop the x: _* syntax (not the functionality) - I’ve never found it clarifying, and I use it just rarely enough to not always remember what it should be. Note that e.g. Java lets you pass an array in place of a vararg - very convenient)
Why not just create:
type OptStr = Option[String]
type OptInt = Option[Int]
type OptDou = Option[Double]
type OptBool = Option[Boolean]
Any plans to support this on a future, or any reasons why this was discarded?
I am specially interested in just the call site ergonomics as @LPTK & @sjrd proposed, as I agree that on the method body values should just be Option[A].
I am reviving this old post because this is something I have always wanted since my early Scala days (about 4 years ago). But, mainly because I have seen many people wanting the same over the time, including colleagues, students, SO users and more recently on the gitter channel.
I was going to start a new topic with my proposal, but decided to search first if it was already discussed, and found this. I am not sure if would have been better to open a new one, apologies if this was the incorrect decision.
IMHO, the best alternative is just auto-wrapping of optional arguments on call site.
This way there is no need to add any new special operator, and all the code that is already written should just work without problems. Additionally, since the scope is very limited, this should not cause strange problems along the way.
I find this specially useful when the arguments have a default value of None. On those cases, when calling the method, having to wrap the value inside a Some seems like pointless boilerplate to me.
I do know there are alternatives to this like, using the cats .some syntax. Or writing overloaded versions of the method to accept plain values. However, this first one, even if nicer, does not reduce a lot of boilerplate at all. And the second one does not scale well when you have more than a couple of arguments, also, it depends on the creator of the code, if it is outside of the user control, then there is nothing to do (well, maybe creating a wrapper over the external code, but that is just more extra boilerplate).
I think that what you are proposing, is an implicit conversion from A to M[A] given Monad[A]:
implicit def wrapInPure[A, M[_]](a: => A)(implicit M: Monad[M]): M[A] =
M.pure(a)
1 Like
I’m generally opposed to this sort of magic. We’re moving away from this sort of thing with the depreciation of the implicit conversions between Scala and Java collections, and for good reasons.
Taking this to an extreme that would be a strawman if it didn’t actually exist, we really don’t want articles like this one written about Scala, instead of about JavaScript.
4 Likes