Using context function parameter by name (and not by type)

Question
1

What should this return ?

def foo(f: (x: Int) ?=> Int) = f(using 0)

val x = 4

foo(x)

Above 3.4.0, it returns 0: x is taken to mean the parameter of f
Before, it returns 4: x is taken to mean the val in scope

I was not able to find any documentation of the 3.4.0 behaviour anywhere, not even in its patch notes

The question is therefore: Is this a bug ?

To me it seems very surprising that the name of a context parameter matters in the first place !

P.S: Scastie replicator
3.4.0 Scastie - An interactive playground for Scala.
3.3.5 Scastie - An interactive playground for Scala.

7 Likes
2

In my (certainly controversial) opinion, it should not compile because you are trying to pass an Int to a context function that takes a named tuple of type (x: Int).

Turns out my expectation is not even true when trying the same with regular functions and named tuples of size > 1:

val myNamedTuple: (x: String, y: Int) = ("foo", 3)

def foo(f: (x: String, y: Int) => Int) = f(myNamedTuple)

Above fails to compile because apparently f expects two separate parameters of types String and Int: Scastie - An interactive playground for Scala.

Edit: by now I learned that naming of function parameters in function types is needed so that one can do things like val f: (x: String) => x.type = ???, so I hereby withdraw my initial opinion.

3

I don’t know. It’s surprising both ways.

On the one hand, if you’re going to take lambdas with named context parameters seriously, what could it possibly mean to say (x: Int) ?=> Int save that when you write code to generate the return Int you have access to x by name? Why not just say Int ?=> Int if that’s what you mean?

On the other hand, mysteriously appearing variables that shadow other variables are, well, mysterious. Parameter names are also mysterious, except that you have to explicitly use syntax for them them in order for them to matter.

So, my considered opinion is: ?!?!

I have a similar degree of uncertainty around

def foo(f: (i: Int, s: String) => String)) = ...

I can call it with this ff as the argument,

val ff: (n: Int, a: String) => String = (a, n) => n*a

which itself is named bizarrely–I swapped the parameter names! But how does that make sense? I see f: and that matters that it’s called f and not something else; but I also have i: and s: and they don’t matter? It’s…a bit weird, especially if you think of the parallel to named tuples where you could certainly pass (Int, String) where (i: Int, s: String) is called for, but you could not pass (n: Int, a: String) where (i: Int, s: String) is called for.

So, in summary, ???!?!?!!

2 Likes
4

I should have used an example that uses x in the type:

trait Foo:
  type Bar
  val b: Bar

def baz(f: (x: Foo) ?=> x.Bar) = 
  f(using new Foo{type Bar = Int; val b = 0})

In this example we need to give a name to the parameter, but we don’t necessarily want that name to pollute the scope

This issue of surprising interactions between named tuples and dependent functions was raised, but not really addressed:

1 Like
5

This definitely breaks some form of soundness:

type A = (x: Int) ?=> x.type
type B = (y: Int) ?=> y.type


def foo[T](y: T) = 0

summon[A =:= B] // works
// => A and B are equivalent, they can be swapped without effect


foo[A](x) // works

foo[B](x) // error: Not found: x
// They are not equivalent after all !
3 Likes
6

I think we really need a syntactic difference between “name I need locally” vs “name I need globally”

Local currently:

  • function parameters
  • (WIP) qualified types

Global currently:

  • implicit function parameter, but only sometimes
  • (experimental) named tuples

The problem being that these constructs can contain each other, otherwise there would be no problem

7

I’d avoid saying “globally”, which is likely to side-track into something we don’t mean here. But I agree that there’s a very surprising scope escape going on here.

Thanks for raising this over on Contributors – this sounds like a problem that needs eyes on it.

2 Likes