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.

Sign up for GitHub

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

Jump to bottom

existential sugar and type projections #3713

Closed
scabug opened this issue Jul 29, 2010 · 4 comments
Closed

existential sugar and type projections #3713

scabug opened this issue Jul 29, 2010 · 4 comments
Assignees
@odersky
Labels
won't fix

Comments

@scabug
Copy link

scabug commented Jul 29, 2010

Summary: I think Map[,]#Inner should be equivalent to x3 rather than an error.

object Test {
  class Map[T1, T2] {
    class Inner
  }
  def f[T1, T2] = { val m = new Map[T1, T2] ; new m.Inner }
  
  // fails - is seen as something like
  // Map[t1, t2] forSome { type t1 ; type t2; } # Inner
  var x1: Map[_,_]#Inner = f[String, Int]
  // error: unbound wildcard type
  //   var x1: Map[_,_]#Inner = null
  
  // syntactically valid, but doesn't do what one probably wants
  var x2: Map[t1 forSome { type t1 }, t2 forSome { type t2 }]#Inner = f[String, Int]
  // error: type mismatch;
  //  found   : Test.Map[String,Int]#Inner
  //  required: Test.Map[t1 forSome { type t1 },t2 forSome { type t2 }]#Inner
  //   var x2: Map[t1 forSome { type t1 }, t2 forSome { type t2 }]#Inner = f[String, Int]
  
  // Winner?
  var x3: Map[t1, t2]#Inner forSome { type t1 ; type t2; } = f[String, Int]
}
@scabug
Copy link
Author

scabug commented Jul 29, 2010

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

@scabug
Copy link
Author

scabug commented Aug 10, 2010

@odersky said:
That would break symmetry. For method param wildcards we interpret

foo(_).bar

as

(x => foo(x)).bar

Types need to behave the same way, or all sanity is lost ;-)

@scabug
Copy link
Author

scabug commented Aug 10, 2010

@paulp said:
Replying to [comment:3 odersky]:

Types need to behave the same way, or all sanity is lost ;-)

I'm happy to take your word for that, but does this mean the shortest way to write this is to be:

Map[t1, t2]#Inner forSome { type t1 ; type t2; }

If Map[,]#Inner is a parse error and the alternative is the above, then at the very least we'd better suggest it in the error message. It is regrettable to impose such a steep syntax penalty: type projections are already unwieldy.

@scabug
Copy link
Author

scabug commented Aug 10, 2010

@odersky said:
I think if you mix wildcards with type projections you should get what you bargained for ;-) -- I never felt a need to write a type like this. These are enormously hairy types ready to devour you in an instant. The bulkier the notation the better it warns you to not go there, which IMO is a good thing.

@scabug scabug closed this as completed May 18, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@odersky odersky

Labels
won't fix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@odersky @scabug