deprecates c.enclosingTree-style APIs #3354
Conversation
ghost
assigned 
|
review @retronym |
| /** The type of compilation units. | ||
| * @see [[scala.reflect.macros.Enclosures]] | ||
| */ | ||
| @deprecated("c.enclosingTree-style APIs are now deprecated; consult the scaladoc for more information", "2.11.0") |
There was a problem hiding this comment.
This should be a link to the Scaladoc of Enclosures.
There was a problem hiding this comment.
The idea here was to both condense the deprecation message and safeguard ourselves against possible hyperlink changes. Maybe we could get away with the link to Enclosures being provided in the scaladocs of deprecated members instead?
There was a problem hiding this comment.
Ideally we'd read the warnings from Scaladoc that tells you if a link target doesn't exist.
There was a problem hiding this comment.
Isn't @see [[scala.reflect.macros.Enclosures]] already a link to the corresponding scaladoc? Or you mean something else?
There was a problem hiding this comment.
Oh sorry I'm misreading this. I thought I was reading the Scaladoc comment, not the deprecation comment.
|
LGTM |
Existing enclosing tree macro APIs face both technical and philosophical problems. On the one hand, it’s close to impossible to provide their robust implementation within the current typer infrastructure. From the very beginning, these APIs have been very experimental, and I was very much hoping to tackle the underlying technical problems, but after a year and a half I can say that it’s still outside our reach. On the other hand, we’re gravitating towards increasingly more local macro expansion, which is in direct contradiction with the existence of c.enclosingTree APIs. Therefore, in order to be able to further evolve macros, we need need additional freedom to reshape the enclosing tree APIs. Therefore I suggest we deprecate the aforementioned APIs and start preparing ourselves to removing them for good in 2.12.0. I hope that existing macros that use these APIs can be reformulated in terms of completely local expansion or be built on top of orthogonal language features (existing ones or new ones, e.g. something like https://groups.google.com/forum/#!topic/scala-debate/f4CLmYShX6Q). Please share your use cases, and I will be glad to help! We have at least the entire 2.12 development cycle ahead of us, so I’m sure we’ll figure this out. Let’s shape robust and scalable reflection API together!
|
Rebased |
|
LGTM |
|
Good to merge as soon as https://scala-webapps.epfl.ch/jenkins/job/pr-scala-test/4722/console succeeds. |
|
retrying the retry: https://scala-webapps.epfl.ch/jenkins/job/pr-scala-test/4725/console |
|
The build linked by Adriaan is green - it's just that the status update is stuck. Therefore I'm merging this pull request without waiting for the kitten to wake up. |
deprecates c.enclosingTree-style APIs
Existing enclosing tree macro APIs face both technical and philosophical problems.
On the one hand, it’s close to impossible to provide their robust
implementation within the current typer infrastructure. From the very
beginning, these APIs have been very experimental, and I was very much
hoping to tackle the underlying technical problems, but after a year and
a half I can say that it’s still outside our reach.
On the other hand, we’re gravitating towards increasingly more local macro
expansion, which is in direct contradiction with the existence of
c.enclosingTree APIs. Therefore, in order to be able to further evolve
macros, we need need additional freedom to reshape the enclosing tree APIs.
Therefore I suggest we deprecate the aforementioned APIs and start
preparing ourselves to removing them for good in 2.12.0.
I hope that existing macros that use these APIs can be reformulated in
terms of completely local expansion or be built on top of orthogonal
language features (existing ones or new ones, e.g. something like
https://groups.google.com/forum/#!topic/scala-debate/f4CLmYShX6Q).
Please share your use cases, and I will be glad to help!
We have at least the entire 2.12 development cycle ahead of us, so I’m
sure we’ll figure this out. Let’s shape robust and scalable reflection
API together!