Fix #8619: Demand transparent for whitebox inlines
#8630
Merged
Conversation
This file contains hidden or 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
Previously, whitebox inlines could be declared in three different ways 1. writing `inline def f <: T = ...` for inline methods 2. writing `inline given f: _ <: T` = ...` for inline givens 3. leaving out the result type for inline methods The last was an oversight, not backed by the spec. It turned out that it was not that easy to implement (3), so it was not done, and afterwards code exploited the loophole. In the new scheme, `whitebox` inlines demand `transparent`. The result type can be given or left out, the effect is the same. The old `<:` result type syntax will be phased out in a subseqent PR once the new syntax is in a release. `transparent` is a soft modifier. It is valid only together with `inline`. Why not allow `transparent` on its own and let it subsume `inline`. The point is that we should steer users firmly towards blackbox macros, since they are much easier to deal with for tooling. This means we want to make whitebox macros strictly more verbose than blackbox macros. Otherwise someone might find `transparent` "nicer" than `inline` and simply use it on these grounds without realizing (or caring about) the consequences. For the same reason I did not follow the (otherwise tempting) idea to simply re-use `opaque` instead of `transparent`. An opaque inline kleeps its type on expansion whereas a transparent one gets the type of its expansion. But that would have nudged to user to prefer `inline` over `opaque inline`, so would again have gjven the wrong incentive. On the other hand, `transparent` as a dual of `opaque` is nice. It fits into the same terminology. It's simply that type aliases are transparent by default and have to be made opaque with a modifier, whereas inline methods are opaque by default, and have to be made transparent by a modifier.
nicolasstucki
suggested changes
Mar 30, 2020
This was missed before.
nicolasstucki
approved these changes
Mar 31, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously, whitebox inlines could be declared in three different ways
inline def f <: T = ...for inline methodsinline given f as _ <: T= ...` for inline givensThe last was an oversight, not backed by the spec. It turned out that it
was not that easy to prevent (3), so it was not done, and afterwards
code exploited the loophole.
In the new scheme, "whitebox" inlines demand
transparent. The result typecan be given or left out, the effect is the same. The old
<:result typesyntax will be phased out in a subseqent PR once the new syntax is in a release.
transparentis a soft modifier. It is valid only together withinline. Why notallow
transparenton its own and let it subsumeinline? The point is thatwe should steer users firmly towards blackbox macros, since they are much
easier to deal with for tooling. This means we want to make whitebox macros
strictly more verbose than blackbox macros. Otherwise someone might find
transparent"nicer" thaninlineand simply use it on these grounds withoutrealizing (or caring about) the consequences.
For the same reason I did not follow the (otherwise tempting) idea to simply
re-use
opaqueinstead oftransparent. An opaque inline keeps its type onexpansion whereas a transparent one gets the type of its expansion. But that
would have nudged to user to prefer
inlineoveropaque inline, so wouldagain have gjven the wrong incentive.
On the other hand,
transparentas a dual ofopaqueis nice. It fits intothe same terminology. It's simply that type aliases are transparent by default
and have to be made opaque with a modifier, whereas inline methods are opaque
by default, and have to be made transparent by a modifier.