Skip to content

Syntax change for wildcards and type lambas #4223

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

Closed
japgolly opened this issue Mar 31, 2018 · 4 comments
Closed

Syntax change for wildcards and type lambas #4223

japgolly opened this issue Mar 31, 2018 · 4 comments

Comments

@japgolly
Copy link
Contributor

Currently we have:

Set[_ <: X] // wildcards
type Reader[I, A] = Freer[[T] => Ask[I, T], A] // type lambdas

Looking outside a little we see that:

  • In Cousin Java, wildcards are ?
  • Term-level lambdas allow _ to be used in place of an lambda args

It would be nice to make this consistent at the type level like the following:

Set[? <: X] // wildcards
type Reader[I, A] = Freer[Ask[I, _], A] // type lambdas
@odersky
Copy link
Contributor

odersky commented Mar 31, 2018

I agree, it would be great if we could do this. But how to get from here to there? We'd need to

  1. Introduce ? syntax as an alternate for _. This breaks all programs that use kind-projector.
  2. Deprecate _ as wildcard syntax, and add a rewrite rule that maps _ to ?.
  3. Disallow _ as wildcard syntax.
  4. Re-introduce _ as a placeholder of a type lambda.

It seems each step requires a major release, and we cannot compress the schedule. Furthermore, it's difficult even to get started on that path because of the conflicts with kind projector. So I don't think we can take the first step with 2.13.

Or maybe add it under -language:future? It would be also great if kind-projector could cooperate, possibly by using ?? instead of ?.

@japgolly
Copy link
Contributor Author

Ignoring kind-projector for now (mainly just 'cos my brain is nearly off and I need to sleep), could we not just do steps 2-4 in a single major release and provide a rewrite rule? I don't think it's unreasonable amount of change for a major release especially if the migration can be trivially automated.

And if not 2.13 (which I wasn't considering anyway TBH), it wouldn't be a problem to do in Dotty before 1.0 and its backwards-compatibility becomes set, would it?

@smarter
Copy link
Member

smarter commented Mar 31, 2018

Duplicate of #2041

@smarter smarter marked this as a duplicate of #2041 Mar 31, 2018
@smarter smarter closed this as completed Mar 31, 2018
@odersky
Copy link
Contributor

odersky commented Apr 1, 2018

gnoring kind-projector for now (mainly just 'cos my brain is nearly off and I need to sleep), could we not just do steps 2-4 in a single major release and provide a rewrite rule? I don't think it's unreasonable amount of change for a major release especially if the migration can be trivially automated.

The problem is cross-building. You can't support new and old versions with the same source then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants