Idea: expanding `?` ( three of those, which are prohibited in titles by the title prettify setting)


??? is really useful, particularly as a method stub or end of method stub.

It could however be more useful. I can think of two ways:

  1. Give it a type hint:
def ???[A]: A = throw new NotImplementedError 

That could help with giving type hints that can aid in inference, for example when ??? is used as a parameter to a function requiring multiple type parameters. It’s not a big thing, but it seems to me to be strictly more useful than the current ???

2.Give it a brother that is a function:

def ????[A](swallow: Any*): A =  throw new NotImplementedError 

This is useful for swallowing any unused parameters or values in your stub, without them leaking in to warnings about unused parameters.

def toBeImplemented(a: Int, b: Double): String = ????(a, b)

of course, you sometimes want to do that later as well

def workingOnThis(a: Int): String = {
  * lots
  * of
  * suff
   ????(stuff, introduced, above)

Do others see this as useful? Useful enough to include in the stdlib?


You can already do this, since expr: Type is allowed as an expression. For example:

sealed trait MyType

def noop[A](x: A): A = x

def workInProgress = noop(???: MyType)

// inferred as workInProgress: MyType

In that case I would rather just make ??? disable unused parameter warnings for the surrounding function, since that’s the only case I could imagine where that would be useful.


AFAIK that would require much more machinery than just adding a oneliner method to predef - probably special handling in the compiler. Why would you find that preferable?


That’s a good point. I was thinking about it from a user perspective and forgot to keep the implementation cost in mind.


Careful! ???! would be parsed as one word. You need a space. But indeed, it
would be no more characters to just add a type ascription.


IMO every ??? should be a warning, so you don’t forget them. ??? is great
for “hole-oriented programming,” meaning you can leave unfinished “holes”,
sketch out the rest of the code, and come back), but you do need to fill in
the holes eventually. And if you use ???, you are ignoring some


That’s a reasonable point. But using the unused variables/arguments warning for it is IMO the wrong warning - having it emit a custom warning would be much nicer IMO.


No one said the unused parameter warning is warning for the ???. What I
meant is that if you’re using ???, the last thing you should be complaining
about is that the compiler notices you’re ignoring your parameters. The
compiler is right to warn you. If anything it should have more warnings,
not less.

I can see why it might cause problems for someone who configures their
build to fail on warnings. Hopefully at least that wouldn’t prevent it from
showing actual errors.



You could prevent a warning about unused parameters like this:

def m[A, B, C, D](a: A, b: B, c: C): D = {

  • val abcToD: (A, B, C) => D = ???*

  • abcToD(a, b, c)*

    Best, Oliver


You don’t get unused warnings for macros:

def f(x: Int): Int = macro ????      // macro impl can warn if f is used
def f(x: Int): Int = ????            // or warn that f is not implemented

A macro can also optionally emit a warning; it’s possibly a feature that the warning would be emitted only if the method is used. The macro could also obey a flag like @ elidable, or rewrite to an elidable method.

def ??!: Int = ???

Making the signatures align is not convenient.

Also I just submitted a PR not to warn for

def f(x: Int) = ???