Hi, On Fri, May 13, 2022 at 2:33 PM Timon de Groot <tdegroo...@gmail.com> wrote:
> Hi internals, > > Almost a year ago I first proposed my RFC draft to introduce a new > json_encode parameter 'indent'. I have received a lot of feedback on the > change, very insightful. The feedback can be boiled down to: > - Accepting user input characters means you could create invalid JSON. > Do we want that? Should it be complying with the spec[1]? > - Preference for pure types, so int OR string, not both. > > So I think I made the change more complex than it should have been and > considered the three options: > 1) Accept indent as an int, which will result in N spaces of indent > per indentation level. > 2) Accept indent as a string, which will result in string N per > indentation level. > 3) Accept indent as an int and indent_char as string, which will > result in N * indent_char per indentation level. > > Option 1 seems very simple and feasible while not being confusing. > Option 2 seems feasible, but somewhat more complex, because user input > should be validated. > Option 3 seems very flexible, but in my opinion very confusing at the > same time, while I'm not sure there's even a use case for this level of > flexibility. > > I have updated the pull request[2] and RFC[3] to be based on option 1, > as I think this offers clear functionality and I feel like I can't > really go wrong with the indent parameter as an int. > > Please let me know what your thoughts are and what needs to be done to > get this RFC going forward! > > I think we can put this RFC to the vote. If the author is to busy I would like to start voting later this week. It would be a pity not to make it to feature freeze as it is quite straight forward and the implementation seems good as well so I guess we don't need to wait extra year. :) Cheers Jakub
