> Therefore the branch name also needs changing :)
>
> Please resubmit under a new name and follow/prerequisite this approach:
> https://code.launchpad.net/~vanvugt/mir/deprecate-without-
> pragmas/+merge/309532
>
> That will then let us do all this in a dozen or so lines of code rather than
> thousands.
There are three cases to consider:
1. the implementation of a deprecated feature should compile (and will be deleted).
2. a test of a deprecated feature should compile (and will be deleted).
3. an "internal" use of a deprecated feature should /not/ compile "silently".
Both this approach and your alternative address cases 1 & 2.
Your alternative approach makes it much harder to identify and address case 3. An "internal" use should either be migrated to the proposed alternative or "flagged" (e.g. with a pragma) for migration *prior* to deleting the implementation.
First flagging everything with pragmas may be "noisier", but it gets us to a better place for managing migration.
> Therefore the branch name also needs changing :) /code.launchpad .net/~vanvugt/ mir/deprecate- without- +merge/ 309532
>
> Please resubmit under a new name and follow/prerequisite this approach:
> https:/
> pragmas/
>
> That will then let us do all this in a dozen or so lines of code rather than
> thousands.
There are three cases to consider:
1. the implementation of a deprecated feature should compile (and will be deleted).
2. a test of a deprecated feature should compile (and will be deleted).
3. an "internal" use of a deprecated feature should /not/ compile "silently".
Both this approach and your alternative address cases 1 & 2.
Your alternative approach makes it much harder to identify and address case 3. An "internal" use should either be migrated to the proposed alternative or "flagged" (e.g. with a pragma) for migration *prior* to deleting the implementation.
First flagging everything with pragmas may be "noisier", but it gets us to a better place for managing migration.