On Sun, Jul 26, 2020 at 11:40 PM Chris Lattner <clattner at nondot.org> wrote: > > On Jul 24, 2020, at 9:50 AM, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Besides, I think you misunderstood: the point isn't to *forbid* >> flag-day changes. The point is to encourage thinking about how to do >> refactoring better. Sometimes a flag-day change is required, and >> that's fine, but in the vast majority of cases it isn't. > > > No I perfectly understood, I'm still not in favor of codifying an encouragement in this direction: I'm not eager to have reviewers ask me to change my patch to follow the scheme you describe for stability purposes. > > > I can see both sides of this. Deprecation has a lot of value that Nicolai points out and some people do use it. I donât think it is possible to get to perfect âdeprecation cyclesâ and even outside perfection an overly-broad application of this would just be expensive. Some things (e.g. core IR) simply matter more than others. > > Perhaps a way too slice this is to phrase it along the lines of: > > 1) There is no guarantee. > 2) That said, for core IR changes it is nice to stage them for XYZ reasons. > 3) If you do so, âthis is the right way". That sounds good to me. Cheers, Nicolai > > -Chris -- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4