Pre-SIP: Optional parameters by symetry with varargs

[Sporarum]

@ragnar

My impression of this proposal was that it results in something very similar to the Converion[A, Option[A]] proposal when considering into.

That makes a lot of sense given they try to solve the same problem !

---

@ragnar

But I could not come up with a case where the ambiguity would be a problem.

Here are some basic ones:

@Sporarum

It would make call-sites behave weirdly:

def foo[T](x: Option[T]) = x

val x = 4

foo(x)       // Some(4)
foo(Some(x)) // Some(4)
// They return the same value

val y = Some(4)

foo(y)       // Some(4)
foo(Some(y)) // Some(Some(4))
// They don't return the same value

def forwarder[T](x: T) = foo(x)

forwarder(x) // Some(4) == foo(x)
forwarder(y) // Some(Some(4)) != foo(y) !!!
// Creating a forwarder changes semantics

(SLC: `Conversion[A, Option[A]]` - #11 by Sporarum)

See also SLC: `Conversion[A, Option[A]]` - #24 by Sporarum for a more realistic example

---

@ragnar

Even with varargs, I have seen libraries to just add an overload that allows passing a Seq without *, and part of me wonders if that syntax could not also just be removed. It feels like something that was adopted from dynamic languages that need syntax to disambiguate the intended types.

Given all the theoretical problems that overloading cause, it feels like any solutions which has similar properties will probably inherit at least some of those issues
(and see the examples above for ways in which it manifests)

---

@ragnar

The ? feels like a very different proposal overall, as its really more about thinking about if the representation of error values. Also it does require explicit nulls.

Yes absolutely, it is a much more complex proposal !
Which is why I think this proposal is valuable, even if only as contrast
(although I aspire for it to be more than that)