Re-name types in policy#937
Conversation
Currently the `policy::Concrete` and `policy::Semantic` types are alias'. We would like to refer to them as `policy::Policy` and `policy::semantic::Semantic` (according to a review suggestion). I believe this is to make it more clear that one shouldn't need to use the semantic policy? Deprecation doesn't work for type alias', just use a code comment to show what is going no. Deprecate the old alias'. Re-export `concrete::Policy` by its own name. Add an alias to `semantic`. Next we will remove the alias and re-name the `semantic::Policy` type. Done separately to make it super obvious what is going on.
To differentiate it from the concrete policy (I think).
After the re-name this stutters. Import type and remove the path.
Introduce a `pollicy::lift` module and move the lifting types and logic there. Add deprecated re-exports although these may not function correctly, I didn't check.
Now we have done re-names and the concrete policy is the 'first class' type in `policy` inline the logic from the submodle to `policy/mod.rs`.
Just use `Policy` now we have done all the re-names.
|
concept ACK these changes. But can you split this into two or three PRs:
Even if the deprecations don't work we should retain the aliases. Then people who are surprised by the breakage in a future version will at least have the ability to fix things by doing the renames then doing the upgrade. |
|
Oh -- to clarify the above. in this PR you move |
|
No worries. One question came to me. Isn't this PR going to wreak havoc on that big local branch you have? Is it worth doing now or should we just wait a bit since this is easy enough to do at any time? |
|
Heh, yeah, it will cause me some chaos, but I suspect I could jury-rig |
As described here: #885 (comment)
Big diff but this is mostly re-names and code moves. I split it up in steps. First might be best to look at the final state of
policy, especially I'm not sure if we want the re-exports left in there considering deprecation doesn't work.