New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Given SI-5009, can case classes with repeated params get a copy method now? #6016
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6016?orig=1 |
@lrytz said: |
Ryan Hendrickson (ryan.hendrickson_bwater) said: case class SureItIs(a: Int)(b: String*) {
def copy(a: Int = this.a): (String*) => SureItIs = new ((String*) => SureItIs) {
def apply(b: String*) = SureItIs(a)(b:_*)
}
} It's just not a valid anonymous function type, but it is most assuredly a valid type. |
@retronym said: All we are told is that:
By name parameters are similarly underspecced. |
@paulp said: The varargs star can only appear in method types, not function types. scala> def f(xs: String*): Int = 5
f: (xs: String*)Int
scala> f _
res0: Seq[String] => Int = <function1>
scala> class A { def g: ((String*) => Int) = f _ }
defined class A
scala> (new A).g _
res1: () => Seq[String] => Int = <function0> |
@paulp said: |
Ryan Hendrickson (ryan.hendrickson_bwater) said: val f: (String*) => Int = new ((String*) => Int) {
def apply(xs: String*) = 5
}
f("hello", "world") Not a method type to be seen, just an anonymous class implementing a valid value type. Jason: I agree that the conformance relation of function types with repeated parameters is underspecified. The existence of those types, however, seems less ambiguous: Syntax:
Semantics:
(In particular, this does not say "function types are shorthands for method types".) So since Any { def apply(xs: String*): Int } is a valid (value, not method!) type, ((String*) => Int) is as well, right? |
@paulp said: scala> val f: (String*) => Int = new ((String*) => Int) { def apply(xs: String*) = 5 }
<console>:4: error: type mismatch;
found : String* => Int
required: Seq[String] => Int It's pointless to debate it too much because all we can do is chase angels around the head of a pin. What we need is a clear statement, not to be spending our time parsing and reparsing the spec hoping it will suddenly become unambiguous through spontaneous disambiguation. |
Ryan Hendrickson (ryan.hendrickson_bwater) said: |
@paulp said: |
Ryan Hendrickson (ryan.hendrickson_bwater) said (edited on Jul 3, 2012 1:08:20 AM UTC): |
@retronym said: Don't feel discouraged -- just because it's hard to solve these issues doesn't mean that you shouldn't be raising them. Unfortunately JIRA is pretty cluttered, and it has a pretty small audience, so discussions in here aren't really that productive. Try the mailing lists instead. The challenge is to summarize and demonstrate the inconsistencies in a way that triggers awareness and discussion from the broader community. You might get a few good ideas there (or you might just here crickets chirping, who knows.) The inconsistencies aren't of the highest priority because you can avoid them by staying away from the underpecified fringes of the languange. There are about 500 other tickets in here that are much harder to avoid. Plenty of those could benefit from your insights and attention to detail, so don't limit yourself to the "repeated and by-name" guy :) |
@retronym said: We can add these to the compiler test suite to make sure the behaviour doesn't drift over time; and it will provide a concrete basis for a wider discussion. |
Ryan Hendrickson (ryan.hendrickson_bwater) said: |
In 2.9, when the copy method had defaults for all parameter lists, having a repeated parameter in any of the lists would prevent the copy method from being generated, since repeated parameters and default arguments can't coexist (though this isn't explicitly spec'd, see #4783). Now that #5009 makes copy return a function type instead of being a multi-param list method, I don't see why it shouldn't be generated if parameter lists after the first one have repeated parameters.
E.g.:
should get a method
The text was updated successfully, but these errors were encountered: