Hi, I think this would best be prototyped as a third party project. One potentially deal-breaking issue I see with this approach is that diffs aren't precise (or rather, what they precisely are doesn't align well with what humans expect). I'd imagine that you'd come up with tons of false positives, where code gets moved around in a refactoring, appears in the diff because of a `go fmt` re-indent (e.g. in a struct or var/const block) or even when it wasn't changed at all, the heuristic just chose the one way to chunk the changes that included the relevant line. Like, I'm sure we all saw plenty of occasions where a commit we reviewed wasn't diff'ed in the way we expected.
Best, Axel On Fri, Nov 20, 2020 at 5:45 AM Hunter Herman <hunterlher...@gmail.com> wrote: > Go can’t break backwards compatibility, but we all know there are apis and > features we wished were removed. > > What if go vet was extended to check if deprecated apis were used in the > current git diff? Go can’t delete apis, but by extending go vet it can push > back hard against their usage. > > It’s like a soft deletion. > > I would personally love for go to be able to start removing apis in this > way. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/A88E356C-7849-4223-B67D-CA2F348708B6%40gmail.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG4q2khyV7KMJMx4K%3DUqhrxm-wudQ8v%3DDHXLgyHGkYoBg%40mail.gmail.com.
