I’m a little bit late to the party, but thank you so much for listening to us on this point
I hope we can settle all together on the minutiae of subtyping for these new exciting types !
(I’ll be happy even if the consensus doesn’t align with my opinions)
And thank you to the SIP committee and compiler team for their continued efforts in improving Scala !
Just a question : how are we going to be able to remove implicit conversions if we introduce features that mandate them?
Could anyone provide some information on what is the status of this bug (it’s biting me in multiple scenarios):
It seems it’s not impossible to import named tuple members:
import language.experimental.namedTuples
def myMethod(tuple: (foo: Int, bar: String)): Unit =
import tuple.foo // Error: value foo is not a member of (foo: Int, bar: String)
println(foo)
myMethod((1, "one"))
I see no mention of imports in the SIP so I’m wondering if this is a design limitation or just a shortcoming of the current implementation?
thanks
Another question I have is whether synthesized TupledFunctions, e.g., obtained through f.tupled should use named tuple.
It doesn’t seem the case at the moment,
> scala --scalac-option -experimental
Welcome to Scala 3.6.2 (23, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
scala> import language.experimental.namedTuples
scala> def foo(x: Int, y: String): Unit = ???
def foo(x: Int, y: String): Unit
scala> foo.tupled
val res0: ((Int, String)) => Unit = scala.Function2$$Lambda/0x000079d96b59aa28@becb93a
I believe spec and implementation are in agreement here. foo is not a “member” of (foo: Int, bar: String). We can use the name foo to select the first element, but that’s not exactly the same thing. And since named imports need to select members, it follows that you can’t use them for a named tuple.
I don’t think they should, that would be quite magical and require a lot of spec and implementation overhead for little gain.
While this is of course true, I think this expectation is a very natural one, and one we will see again and again
Given it seems highly consistent with other features, and unambiguous, shouldn’t we include it as well ?
I wonder if NamedTuple could be made Selectable, and its Fields could be mapped to its own tuple type, and finally if names could be aliased to _1, _2, … through inlining.
For what purpose? It won’t work for pattern matching.
NamedTuples already work with pattern matching. I made this suggestion as a way to make the names be members of the type (through Selectable)
I just realized that NamedTuples as currently implemented are not supported by Mirror.Of unlike regular tuples, it’s not mentioned explicitly in the SIP but I don’t think that’s an intentional omission so I’ve opened Mirror.Of is not implemented for named tuples · Issue #22382 · scala/scala3 · GitHub
Will there be a syntax sugar for default values like opt = None?
could you expand a bit on what you mean?
I think
type Person = (firstname: String, lastname: String, address: String = "")
val jack: Person = ("Jack", "Sparrow") // (firstname = "Jack", ..., address = "")
Wanted to do this example with a pair, but then I ran into the lack of a way to make singleton tuples
For this you would need case class literals
That’s what i mean, to define default values, which can be omitted in name tuple literal constructors, however after rethink, maybe does not make sense for structural types like named tuples, though it does for named functions and nominal classes