Question about Networking, Ranges, Modules and Concepts

[Osman Zakir]

I need to ask: What are the plans of the committee concerning the Networking, Modules, Ranges and Concepts TS's?  I originally wanted to asking about Coroutines as well, but then I read that thread titled "coroutines have odd interaction with std algorithms" and decided against it since it seems like there are obviously some problems with the Coroutines TS right now - hopefully we'll get one of the better versions Nicol talked about when it's all said and done.

If it'd be okay to ask this in this same thread: I want to ask if it's possible for a good HTTP server and client library to be added to the standard.  Once the Networking TS and the Beast library are standardized (they hopefully will be, soon-ish), it'd be good if we also got an HTTP server and client library standardized either at the same time or afterwards.  This is like a pseudo-proposal right now.  I'm not sure if I can stick with the whole process of having an actual proposal standardized, after all.

[Ville Voutilainen]

On 18 December 2017 at 15:22, Osman Zakir <osman...@gmail.com> wrote:
> I need to ask: What are the plans of the committee concerning the
> Networking, Modules, Ranges and Concepts TS's? I originally wanted to
> asking about Coroutines as well, but then I read that thread titled
> "coroutines have odd interaction with std algorithms" and decided against it
> since it seems like there are obviously some problems with the Coroutines TS
> right now - hopefully we'll get one of the better versions Nicol talked
> about when it's all said and done.

Concepts have been merged. Ranges is a merge candidate, maybe for C++20, maybe
later. Same goes for Networking and Modules, although the Modules TS
is not published yet
so it's going to require minor miracles to have Modules in C++20.

> If it'd be okay to ask this in this same thread: I want to ask if it's
> possible for a good HTTP server and client library to be added to the
> standard. Once the Networking TS and the Beast library are standardized
> (they hopefully will be, soon-ish), it'd be good if we also got an HTTP
> server and client library standardized either at the same time or
> afterwards. This is like a pseudo-proposal right now. I'm not sure if I
> can stick with the whole process of having an actual proposal standardized,
> after all.

Possible, sure. How likely that is is anyone's guess, but I would
recommend trying.

[Osman Zakir]

There's a server framework on the Beast library GitHub page that one could try extending to include a client.  How about that? 

[Osman Zakir]

I'll give a link to the server framework I mentioned.  It's not actually the Beast library GitHub page.  Here: https://github.com/fffaraz/awesome-cpp/issues/358

[Osman Zakir]

On Monday, December 18, 2017 at 6:41:26 PM UTC+5, Ville Voutilainen wrote:

Regarding what you said about the Networking TS: Do you mean it's a "maybe in C++20, maybe later" thing like Ranges?  Or do you mean it's going to be in C++20?  I heard it was already approved for publication.  What stages are the Networking and Ranges TS's, respectively, in right now?  If it's okay to ask.  

[Nicol Bolas]

The TS is approved for publication. That doesn't mean it's part of C++20; it just means that its a Technical Specification.

What stages are the Networking and Ranges TS's, respectively, in right now?  If it's okay to ask.

They're published Technical Specifications.

[Ville Voutilainen]

On 19 December 2017 at 01:11, Osman Zakir <osman...@gmail.com> wrote:
> Regarding what you said about the Networking TS: Do you mean it's a "maybe
> in C++20, maybe later" thing like Ranges? Or do you mean it's going to be

Yes.

> in C++20? I heard it was already approved for publication. What stages are

There are no guarantees that either Networking or Ranges will make it
into C++20,
but there's active encouragement to work towards those goals, and
Ranges complements
a major feature that has already been approved into the C++20 working
draft (Concepts).

> the Networking and Ranges TS's, respectively, in right now? If it's okay to
> ask.

They have been published, as was already stated. See
https://isocpp.org/std/status

[Osman Zakir]

I don't understand that status graph thing that well.  Like, I can tell what the stuff with the arrows means, but nothing aside from that.  

Anyway, I'm happy that Networking and Ranges are being actively encouraged for standardization, but I hope it happens ASAP (I don't mean to rush anyone, though).  

And this is probably a dumb question, but: what features and additions does the language need, direct support for web development or no, that would encourage it to be used for that more than it is now?  It seems like people already use it for that when they need the performance and speed boost, but opt to use scripting languages when that is not needed since a lot of the things they want to be able to are harder in C++ and it's generally thought of as a waste of time.  So really, what I'm asking is: What does C++ need to be able to do for it not be thought of as a waste of time, so that web developers will use it more?  I'd really like for this to happen soon if possible (and if the standards committee is also in support of it).   

[Nicol Bolas]

I don't see how this "make C++ useful for web development" thing is going to be anything other than a race C++ can never win. C++ gets updates ever 3 years. The web changes much faster than that. There's no effective way for C++ to keep up in such an environment. Not so long as it advances through ISO standardization.

C++ is good at being what it currently is. We should work on making it better at that. We shouldn't feel like C++ is a lesser language just because it's not used for web development.

[Osman Zakir]

Well, you're right, but then we already have a networking library being added (question is "when") and there's also a Databases proposal being worked on.  So even if it doesn't win said race, more people still might start using it after C++20 or 23 come out at this rate.  

Even making it better at the things it's already used for would make it easier to use in general as well, right?  Most people who don't use it are just shying away due to the difficulty in doing some of the things they want to be able to do. 

My theory is that even if C++ never supports web development directly, as long as it becomes easier to use otherwise, the current situation where people shy away from it will still change.  We still have third party web frameworks and libraries, and MySQL has a C++ Connector library.  And Modern C++ is already a lot easier to use than classic C++ anyway.  That's progress, isn't it?

Anyway, some more questions.  From looking that status graph, I can guess that Concurrency 2 and 2D Graphics are in a "pending" state?  Since both ends are faded out, I guess no one's sure yet when they'll be in, if at all.  What do each of the letters in the table header mean?  And wasn't the File Systems TS already in C++17?  Why is still in the D part?  

[Nicol Bolas]

My overall point is that you shouldn't measure things by "People won't use C++ to do X because it doesn't have a standard library component for doing that."

The thing C++ most needs is a unified build system and library distribution kit. Because that's the thing that keeps all those "third party framworks and libraries" from being out of reach for many C++ programmers: the difficulty of getting a library from someone else and using it. If we could have that, we wouldn't need standard proposals like the 2D graphics library or the database proposal; such libraries could be easily accessible to the people who want them.

But that's not something the ISO C++ standardization committee can actually fix.

Anyway, some more questions.  From looking that status graph, I can guess that Concurrency 2 and 2D Graphics are in a "pending" state? Since both ends are faded out, I guess no one's sure yet when they'll be in, if at all.  What do each of the letters in the table header mean?

It's a spreadsheet. They don't mean anything.

[Alberto Barbati]

Il giorno lunedì 18 dicembre 2017 14:22:06 UTC+1, Osman Zakir ha scritto:

I originally wanted to asking about Coroutines as well, but then I read that thread titled "coroutines have odd interaction with std algorithms" and decided against it since it seems like there are obviously some problems with the Coroutines TS right now - hopefully we'll get one of the better versions Nicol talked about when it's all said and done.

I believe you are overstating the "obvious problems" with the Coroutine TS. The TS has been approved and published. I don't know if and when it will be merged in the standard, Ville didn't mention it and surely he is more knowledgeable than me about that. However, I find it hard to believe that all that work will be thrown away to follow another competing proposal. A more  probable scenario is to have some incremental changes to the TS to allow stackful coroutines in some form, either before or after merging. Just my opinion.

Disclaimer: I like the Coroutine TS as it is and would be more than happy to have it in the standard soon.

[Osman Zakir]

Yeah, it'll be merged alright, but according to what I read, some people are dissatisfied with the TS itself.  Hopefully the problems will be fixed.  

We'll hopefully get a HTTP web server and client added to the standard at some point, but I'm also worried about C++ not having a way to get all third-party open source libraries to C++ programmers easily.  I'm thinking of a solution, one that all C++ compiler vendors will have to work on.  It's to have all compilers shipped with a collection of third-party libraries and make it so that including them in a project is as easy as it is with the standard library.  And hopefully we can get it to a point where no extra linking step is needed.  Instant inclusion so that the programmer can just start coding instantly without any effort on his/her part.  Might seem a bit ambitious, but I think this has to be done if we are to have the C++ community involved with the updates to the language in a more involved way and make it so that any useful library the library authors write will be immediately available to all programmers.   That would be the unified library distribution kit, if we can get work started on it.

As for the build system.  IMO, those same compiler vendors could collaborate and create a single compiler toolchain that the aforementioned collection of third-party libraries will be shipped with.  It should be a compiler that's 100% standards conformant (yes, really - we need that) and should also produce compiler warning and error messages that are easy to understand even for complete beginners.  

Now, thankfully, some people on the committee also have their own compilers.  The chair himself is in Microsoft, for example.  Get him onboard with this somehow.  And we also need to mention this somewhere where it'll reach other compiler vendors as well.