diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2014-01-11 14:48:22 +0100 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2014-01-16 20:19:23 +0300 |
commit | 6f4dfb4c851a02e1c02e4d44988cbf9163ffefd1 (patch) | |
tree | c08c620bfcfb6a19f5d7f91396ee6763bd15ab15 /test/files/neg/t3098.flags | |
parent | 681308a3aa737be1dae0f702fddadce88c70f90e (diff) | |
download | scala-6f4dfb4c851a02e1c02e4d44988cbf9163ffefd1.tar.gz scala-6f4dfb4c851a02e1c02e4d44988cbf9163ffefd1.tar.bz2 scala-6f4dfb4c851a02e1c02e4d44988cbf9163ffefd1.zip |
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!
Diffstat (limited to 'test/files/neg/t3098.flags')
0 files changed, 0 insertions, 0 deletions