cplusplus / draft

C++ standards drafts
http://www.open-std.org/jtc1/sc22/wg21/
5.62k stars 739 forks source link

Reorder [basic] before [lex] #2252

Open zygoloid opened 6 years ago

zygoloid commented 6 years ago

[basic] would make more sense if it appeared prior to [lex] rather than after. Conversely, [lex.separate] and [lex.phases] really belong in [basic], not [lex]. (We should also consider moving [cpp] to immediately after [lex] so that the top-level clauses are in a more logical phase-of-translation order, but keeping it in exile -- as an appendix of sorts -- has some merit too.)

jensmaurer commented 6 years ago

Literally minutes after releasing a draft with the large C++20 renumbering applied do we come up with even further large-scale rearrangements.

tkoeppe commented 6 years ago

Well, there's always force-pushing :-)

jensmaurer commented 3 years ago

Maybe also move the preprocessor section near lex or merge both into a new "lexical processing" clause.

[basic] has some details that need to move later, e.g. allocation/deallocation function details should go to "Declarations".

Operator overloading [over.oper] should partially move to [expr] and to "Declarations".

jensmaurer commented 2 years ago

I have reservations about moving [basic] before [lex]; this needs more internal restructuring.

AlisdairM commented 3 weeks ago

I was working on a PR/paper that would perform the suggested restructuring, and it quickly ended up redistributing most of [lex] across [basic] and [cpp]. In hindsight, the contents of [lex] truly should precede the contents of [basic].

One reorganisation that I believe did help was moving [cpp] to directly follow [lex], per the phases of translation, and then moving [modules] directly after the relocated [cpp] to put all the program composition and source transformation together, before starting on trying to interpret its actual contents. That involved also creating and deploying \firstcoreclause and \lastcoreclause to match \firstlibraryclause and \lastlibraryclause in config.tex.

cor3ntin commented 1 week ago

lex.phases and lex.separate don't belong in lex, but lex really is better before basic so I don't see a good solution. I really would be against splitting the rest of lex. lex is starting to be in good shape.

[modules] is in sort of a weird place - but it needs to be after [dcl] to make sense (or at least after basic). [cpp] does belong after [lex]. I think it was pushed to the end because well, it's [cpp].

We could do either of these somewhat targeted changes:

The status quo does not prevent me to sleep, this would be a marginal improvement

zygoloid commented 6 days ago

There has historically been resistance to moving [cpp] -- some have said they like having [cpp] as a neutral zone / buffer between core and library :) -- but I think logically [cpp] belongs towards the start of the standard, next to [lex] (actually in the middle of [lex] as it stands...).

There are some other issues in the presentation of [lex], mostly stemming from preprocessing token concerns getting mixed up with token concerns and phase 7 concerns. For example, most of [lex.ext] is talking about phase 7 things, and various other sections on literals talk about the meaning of expressions rather than anything to do with lexing.

If I were doing things over from scratch, I'd have a section describing phases 1-3 (and only phases 1-3), then a section describing phase 4, and I'd remove phases 5 and 6 (and instead specify that certain phase 7 grammar productions consume a sequence of string-literal tokens, not just one). And then a bunch of phase 7 stuff.

AlisdairM commented 6 days ago

I have been working to address this issue in the background, and finally pushed my suggested refactoring in #7153.

This is NOT mergeable as it is based off something closer to N4981, the pre-St Louis draft. It is a vision of changes I would like to incrementally apply for the next mailing.

In particular, it gives up on merging parts of [lex] and [basic] as I could not find a satisfying merge, and instead focused on doing its best job on putting up front the parts that specify how to arrange source text to build a program.

The most obvious change is merging [cpp] into [lex], as both were small clauses the combined clause is closer to the average page count, but still low. I looked at merging the similarly small [modules], but did not find a good factoring at this time.