-
Notifications
You must be signed in to change notification settings - Fork 1k
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
SIP - Allow multiple implicit parameter lists #520
Closed
Closed
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
ebe6ba6
Initial draft for multiple implicit parameter lists SIP
mgttlinger 00cd664
Minor edits for clarity
philwills 4f7b2c6
Merge pull request #1 from philwills/multiple-implicit-params-sip-edit
mgttlinger e4e08a8
implicit keyword in every implicit list
mgttlinger b486dfd
Fixed typos
mgttlinger 538aa0d
Added reference to Travis' blogpost as recommended by Jason
mgttlinger File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
65 changes: 65 additions & 0 deletions
65
sips/pending/_posts/2016-04-21-multiple-implicit-parameter-lists.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
--- | ||
layout: sip | ||
disqus: true | ||
title: SIP-NN - SIP Allow multiple implicit parameter lists | ||
--- | ||
|
||
**By: Miles Sabin and Merlin Göttlinger** | ||
|
||
## History | ||
|
||
| Date | Version | | ||
|---------------|---------------| | ||
| Apr 21st 2016 | Initial Draft | | ||
|
||
## Motivation | ||
|
||
Currently, the implicit parameters of a function are limited to being placed in a single, final, parameter list of a function. This prevents later parameters from using dependant types of former ones, as this is only allowed between, but not inside a single parameter list. | ||
|
||
This restriction also means that if you want to explicitly specify one of the implicit parameters you have to specify all of them by hand (or write `implicitly` in place of every other parameter that should be filled by the compiler). | ||
|
||
## Motivating Examples | ||
|
||
### Examples | ||
|
||
For regular parameter lists it is possible to write the following: | ||
{% highlight scala %} | ||
trait A { type B } | ||
|
||
def works(a: A)(b: a.B) = "works" | ||
{% endhighlight %} | ||
Due to the restriction of being contained in a single parameter list, implicit parameters can't work in the same way. A common workaround is to pull the type member `B` into a type parameter of a new `Aux` object and make this a type parameter of your function: | ||
{% highlight scala %} | ||
trait A { type B } | ||
object A { type Aux[D] = A { type B = D } } | ||
|
||
def works[B](implicit a: A.Aux[B], b: B) = "works" | ||
{% endhighlight %} | ||
While this works it introduces unnecessary complexity because our method shouldn't need to have type parameters and we shouldn't need the `Aux` object just to use the type member of `A` for implicits. | ||
|
||
With the proposed change of allowing multiple implicit parameter lists the example would again be reduced to the following concise and readable example: | ||
{% highlight scala %} | ||
trait A { type B } | ||
|
||
def worksWithImplicits(implicit a: A)(implicit b: a.B) = "pls make me work" | ||
{% endhighlight %} | ||
|
||
Another benefit mentioned before would be that implicit parameters, that are expected to often be filled in manually can be put in separate lists. | ||
{% highlight scala %} | ||
def now(implicit a: Int, b: String) = b * a | ||
now(1, implicitly) | ||
|
||
def then(implicit a: Int)(implicit b: String) = b * a | ||
then(1) | ||
{% endhighlight %} | ||
|
||
## Implementation | ||
|
||
The implementation of this change is as simple as removing the restriction of having only one parameter list in the `Parser`. A pull request (#5108) from Miles Sabin already implements this change as well as an accompanying test file. The change should not affect any existing code as every Scala statement that was valid before will still be valid after the change. There will even be binary compatibility in both directions. | ||
The desugaring ob context and view bounds will be added on the left of the leftmost implicit parameter list to go with the general expectation from the current implementation. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/ob/of |
||
|
||
## References | ||
|
||
1. [Miles' PR][1] | ||
|
||
[1]: https://github.com/scala/scala/pull/5108 "PR#5108" |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/dependant/dependent