Rename `newline` to `line_break`.
Rename newline to line_break in all places where it now means a set of characters, not specifically the \n character.
We also have an alias attribute so that users don't lose the method they are interested in
While in retrospect I would have used a different name, history is as it is now, and I don't want to be changing names and breaking parsers without a good technical reason.
I am happy for the alias attribute to be applied so that searching for 'line break' in the docs takes a user to the newline parser and to see the docs changed to point out that it technically parses a line break, of course.
While in retrospect I would have used a different name, history is as it is now, and I don't want to be changing names and breaking parsers without a good technical reason.
But you already agreed to this earlier, when we discussed it in discord...
I've just searched through our conversation and I can't find evidence of that, but perhaps I'm missing something. My justification is the same for other rename proposals:
I'm just not happy with renaming such a fundamental method, that people remember and use instinctively, this far into development, for such weak reasons. A major version increase doesn't mean that we should pack as many breaking changes in as we can. It is still extremely annoying for users to update a library and find that they have dozens of compilation errors to fix - all for an entirely non-technical reason.
To continue my reasoning further: chumsky has about 10 million downloads on crates.io. Granted, that probably only translates to a few thousand active users. But that still means that if you make a change that forces each one of them to spend 10 minutes scratching their head, reading changelogs, and then making a change that's maybe ~10k-50k minutes or about 200-1000 person-hours. I personally would not decide to spend several months of my life working 8 hours a day to fix something that doesn't even meet the threshold of 'typo'
I accept that on a technicality, the name is not correct. But it is colloquially accurate, and the docs are very clear about the exact behaviour of the function.