Scala fusiona los parámetros de llamadas a múltiples funciones en un Tuple. ¿Se puede deshabilitar?

Question

Esta es una violación problemática de la seguridad de tipo en mi proyecto, por lo que estoy buscando una forma de desactivarla. Parece que si una función toma un AnyRef (o un java.lang.Object), puede llamar a la función con cualquier combinación de parámetros, y Scala fusionará los parámetros en un objeto Tuple e invocará la función.

En mi caso, la función no espera un Tuple y falla en tiempo de ejecución. Esperaría que esta situación fuera atrapada en tiempo de compilación.

object WhyTuple { 
def main(args: Array[String]): Unit = { 
    fooIt("foo", "bar") 
} 
def fooIt(o: AnyRef) { 
    println(o.toString) 
} 
} 

de salida:

(foo,bar) 

Answer 1

La compilación es capaz de interpretar métodos sin paréntesis. Por lo tanto, toma los corchetes de la ronda en el sentido de Tuple. Su llamada es lo mismo que:

fooIt(("foo","bar")) 

Dicho esto, se puede hacer que el método para excluir la llamada, y recuperar el valor si se utiliza algún envoltorio al igual que algunos (AnyRef) o TUPLE1 (AnyRef).

Answer 2

Creo que la definición de (x, y) en Predef es responsable. El indicador del compilador "-Y-no-predefs" puede ser de alguna utilidad, suponiendo que estés dispuesto a hacer el trabajo de importar manualmente cualquier implicito que necesites. Con eso quiero decir que tendrás que agregar scala.Predef._ de importación por todo el lugar.

Answer 3

Editar: De acuerdo con las personas mejor informadas que yo, la siguiente respuesta es realmente incorrecta: ver this answer. Gracias Aaron Novstrup por señalar esto.

Esto es en realidad un capricho del analizador , no del sistema de tipo o el compilador. Scala permite que se invoquen funciones de cero o de una arg sin paréntesis, pero no funciones con más de un argumento. Entonces, como Fred Haslam says, lo que ha escrito no es una invocación con dos argumentos, es una invocación con un argumento de tupla-valor. Sin embargo, si el método hizo toma dos argumentos, la invocación sería sería una invocación de dos arg. Parece que el significado del código afecta la forma en que analiza (que es un poco suckful).

En cuanto a lo que realmente puede hacer al respecto, es complicado. Si el método realmente requería dos argumentos, este problema desaparecería (es decir, si alguien intentara llamarlo por error con un argumento o con tres, obtendría un error de compilación como esperaba). ¿No crees que hay algún parámetro adicional que has estado posponiendo para agregar a ese método? :)

Answer 4

¿Qué pasa algo como esto:

object Qx2 { 
    @deprecated def callingWithATupleProducesAWarning(a: Product) = 2 
    def callingWithATupleProducesAWarning(a: Any) = 3 
} 

tuplas tienen el rasgo de producto, por lo que cualquier llamada a callingWithATupleProducesAWarning que pasa una tupla producirá un aviso de desaprobación.

Answer 5

No implicits o Predef en juego aquí en absoluto - solo buena magia de compilador pasada de moda. Puede encontrarlo en el type checker. No puedo ubicarlo en la especificación en este momento.

Si está lo suficientemente motivado, podría agregar una opción -X al compilador para evitar esto.

Como alternativa, puede evitar escribir los métodos arity-1 que aceptan un supertipo de TupleN.

Answer 6

¿Podría también agregar una anulación de dos param, que evitaría que el compilador aplicara el azúcar sintáctico? Al hacer que los tipos sean adecuadamente oscuros, es poco probable que obtenga falsos positivos. E.g:

object WhyTuple { 

    ... 

    class DummyType 

    def fooIt(a: DummyType, b: DummyType) { 
    throw new UnsupportedOperationException("Dummy function - should not be called") 
    } 
}