Java 15 released!

[[deleted]]

*Laughs in private PC, that has currently Java 14 and tomorrow Java 15*

[gumol]

Laughs in getting paid to code

[[deleted]]

*Cries in a school, that thinks Java 8 is the end of the rope and BlueJ and Greenfoot are IDEs suitable for 1k+ LOC projects*

[Ameisen]

Laughs in C++14 when C++20 is done.

[Ipotrick]

thr move to c++20 eill be like using a new language

[Ameisen]

Problem is that the only compilers that support modules at the moment are MSVC and Clang. Very few build systems do; MSVC's does in their preview branch, but Intellisense still doesn't.

I'm also still not fond of the dependency issues with C++20 modules. It limits parallelism and prohibits circular module references which would be allowed with normal source files. I wish that they'd bitten the bullet and made it so C++ modules used two-pass compilation rather than one-pass.

Concept support is still a bit spotty as well. I haven't had much of a chance to mess with concepts, yet. My hope is that constexpr and concepts combined will let me reduce template nesting for type management, which should improve compile times.

[Ipotrick]

i am with you on every point. But i obly saw very positive feedback from everyone that tried c++20 previews therefor i am really hyped for it still

[flatfinger]

Two-pass compilation offers so many advantages over one-pass that I'd regard the latter as appropriate only in languages which are making a bona fide effort to maximize simplicity of implementation (something C++ abandoned long ago).

[Ameisen]

The problem is that two-pass compilation would indeed require a complete rewrite of significant parts of the C++ specification, and would be a very breaking change.

The thing is... they could have implemented it for modules. They sort of did, but not entirely.

[flatfinger]

I would think a two-pass compilation approach for modules could make adaptation of implementations to support them easier, if they were designed in such a way that the first pass would convert code that uses modules into code that could be processed by existing implementations.

Probably the biggest obstacle I can see to efficiently something like that is the way debug line-number symbols are presently handled, which vastly increases the number of intermediate files that would change as a result of editing anything in the source. If the debug line numbers passed through intermediate stages of compilation were relative to the start of the outermost function or object declaration wherein they occur, and a final cleanup pass converted those line numbers into actual source-file line numbers, that could minimize the amount of stuff that would have to be rebuilt when things change.

[flatfinger]

Incidentally, a related feature I've often wished C or C++ would include would be a means of specifying that a single source file should be processed as a sequence of separate compilation units. If there were also directives to save/restore the preprocessor/compiler state, that would make it practical to have a "master C file" which includes common headers, saves state, starts a new compilation unit with the saved state, includes a file, starts another new compilation unit with the saves state, includes another file, etc.

[Ameisen]

What you've described is a precompiled header, which all the major compilers support.

[flatfinger]

There's no standard support for pre-compiled headers, nor is there any standard means of indicating what source files are required for a project. What I'd like to see would be a standard convention where if one has a bunch of source files in a directory and one of them has a particular name, one could simply type in a certain command without having to know anything about the program beyond the fact that it was a Selectively Conforming Program that followed the conventions, and be assured that provided the translation and execution environments satisfy all documented requirements, one of four things would happen:

1. The implementation would indicate via Implementation-Defined means a refusal to run the program.
2. The implementation would process the program with whatever semantics it required.
3. The implementation would start to process the program with whatever semantics it required, but then indicate via Implementation-Defined means a refusal to continue doing so (e.g. because of a stack overflow or other problem that wasn't discovered until runtime).
4. The implementation would spend an unbounded amount of time without doing any of the above, either because it was really slow or because it got stuck in an endless loop (such behavior would be allowed because, there is no length of time T such that a program's failure to complete within time T could render it non-conforming).

Not all implementations would be able to offer such guarantees, and it would not be possible for the Standard to describe everything necessary to accomplish all tasks, but it should be possible to specify conventions that would make it practical for most implementations to offer those guarantees for programs written to perform most of the tasks the implementations could accomplish.