Skip to content
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

well-formedness of compound types: spec is stricter than implementation #3512

Closed
scabug opened this issue May 31, 2010 · 3 comments
Closed
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented May 31, 2010

from the spec:

A compound type T1 with...with Tn {R} represents objects with members as
given in the component types T1 ,..., Tn and the refinement {R}. A refinement {R}
contains declarations and type definitions. If a declaration or definition overrides a
declaration or definition in one of the component types T1 ,..., Tn , the usual rules
for overriding (�5.1.4) apply;

5.1.4 Overriding
A member M of class C that matches (�5.1.3) a non-private member M' of a base
class of C is said to override that member. In this case the binding of the overriding
member M must subsume (�3.5.2) the binding of the overridden member M' .

5.1.3 Definition 5.1.4 A member definition M matches a member definition M' , if M and
M' bind the same name, and one of following holds.

  1. Neither M nor M' is a method definition.

3.5.2 A declaration or definition in some compound type of class type C subsumes an-
other declaration of the same name in some compound type or class type C' , if one
of the following holds.

  • A type alias type t [T1 ,..., Tn ] = T subsumes a type alias
    type t [T1 ,..., Tn ] = T' if T ≡ T' .
  • A type declaration type t [T1 ,..., Tn ] >: L <: U subsumes a type declaration
    type t [T1 ,..., Tn ] >: L′ <: U' if L′ <: L and U <: U' .

code examples that say otherwise:

object T {
  trait A {
    type X <: Int
  }
  
  type S = A{type X = String}
}

this should give a type error according the spec;
since it is not specified when compound types need to adhere to the rules from the first paragraph above,
it would be reasonable to assume they should always adhere
I guess it's a spec issue, not an implementation one
see also #3419 and neg/bug1275

object Bug1275 {
  trait Seq[+t] {
    type MyType[+t] <: Seq[t]

    def f: MyType[t]
  }

  // illegal abstract type member refinement: changes the arity of MyType
  // the error is pretty strange, since the compiler forms the illegal type xs.MyType[a] anyway
  def span[a, s <: Seq[a] { type MyType/*look ma, no type parameters!*/ <: s } ](xs: s): s
     = xs f
//        ^
// found   : xs.MyType[a]
// required: s  
}
@scabug
Copy link
Author

scabug commented May 31, 2010

Imported From: https://issues.scala-lang.org/browse/SI-3512?orig=1
Reporter: @adriaanm

@scabug
Copy link
Author

scabug commented Aug 13, 2010

@adriaanm said:
(In r22754) closes #3419: test files

omit check that wouldn't work with separate compilation,
not needed anymore because compiler has become more robust

the actual fix was committed as part of r22512, see #3374

also see #3512

no review

@scabug
Copy link
Author

scabug commented Oct 15, 2013

@gkossakowski said:
Unassigning and rescheduling to M7 as previous deadline was missed.

@scabug scabug closed this as completed Mar 13, 2014
@scabug scabug added this to the 2.11.0-RC3 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants