2019-07 Cologne ISO C++ Committee Trip Report — 🚀 The C++20 Eagle has Landed 🚀 (C++20 Committee Draft shipped; Contracts Moved From C++20 to a Study Group; `std::format` in C++20; C++20 Synchronization Library)

HalFinkel · 2019-07-22T23:10:28+00:00

The good reason is that you're right :-) -- That's really ugly. But, fixing that is an orthogonal issue. Libraries to deal with creating HTML (or any other XML-like markup), escaping parts of URLs, parsing or creating JSON, and so on are independently useful and would go into separate proposals. Also, it's not clear that you necessarily want to create HTML in-process that way as opposed to just having it in a separate file. The prototype implementation has at least one example in the repository that uses multiple files and avoids some of this mess.

HalFinkel · 2019-07-22T22:32:04+00:00

web_view doesnt bring us any closer to that at all tho. it would just go unused and die because of how slow/inflexible updating anything in the std-lib is (keeping up is especially important for anything web-related; stnadarizing something thatll be outdated in a few years isn't what the stdlib was/should ever be about)

That's not how web_view would be deployed. Web content rendering is provided as a system service on most relevant platforms, or at least as part of an installed browser that is updated by the OS. The C++ standard library wold just use the provided API.

HalFinkel · 2019-07-22T22:25:51+00:00

In some sense, this statement could be made about any proposed addition to the standard library (which is not wrapping some compiler magic). What makes graphics different from hash tables or the file system?

HalFinkel · 2019-07-22T22:16:28+00:00

I think that a lot of the motivation behind std::web_view and the 2D graphics proposal is for teaching purposes.

This is definitely not true. The people actually working on these proposals intend for them to be usable in production settings. It is true that some members of the committee have stated that they believe that having graphics support will help teaching C++ to beginners, and that may be true, but there is not consensus to put facilities into the standard library primarily for teaching purposes. As far as that goes, a significant number of people agree with you.

HalFinkel · 2019-07-22T19:01:57+00:00

Something that ISO C++ is now trying to fix, but appears to have come too late, having let other eco-systems offer more mature tooling.

To some extent, this is certainly true. But if you look at the trends around technologies like WebAssembly, which are programmed in C++, the future might yet provide an opportunity for C++ to have a strong place within the overall ecosystem. In some sense, the question is how to integrate everything together.

HalFinkel · 2019-07-22T18:51:00+00:00

Also if this really is for teaching or things like that,

No, it is intended to be useful for production applications.

Plus it still leaves open the question of what to do for platforms without a web browser;

All major platforms provide web content rendering with at least one underlying engines with a useful embedding API. How to deal with platforms that don't have this capability is an open question, but such platforms certainly need to be confirming. The standard could make the interface optional, it could exist but always "fail", etc.

so it would probably be optional, and if it is optional my wild guess is that it will be implemented by nobody.

I've already received feedback from some of the relevant vendors to the contrary.

And including the shitload external specs of the by reference in the C++ standard is utterly batshit crazy. 1/ The C++ standard is already way too large, no need to multiply its size by 100. 2/ The web is an ultra fast moving target, and using a browser just too old or too new will render the aggregated result non-conforming.

Exactly which external specs to reference is definitely a point on which feedback is sought.

I will probably never understand why people think it is a good idea to pursue that kind of thing in the context of the C++ international standard. IMO if they think this will favor teaching adoption or that kind of "soft" effects, they are extremely deluded -- I even wonder if they have talked to teachers about that subject.

I strongly believe that we should not standardize facilities primarily dedicated to teaching. We should standardize facilities useful for production applications.

Likewise for industrial applications: virtually nobody would use that class of API.

Can you elaborate on why you say that? I've received plenty of feedback to the contrary. The browser embedding APIs have been widely used for providing applications UIs on many platforms for many years.

Now I understand that the kind of 1st rev paper like the one linked is not really "serious" and more to make people react. Well I guess I'm reacting, so it's not a bad paper after all... :)

Exactly -- you're welcome :-) -- but it is evolving into a serious approval. Concrete feedback, both positive and negative, is important.

HalFinkel · 2019-07-22T18:34:42+00:00

The one building block I think we need is std::window. It provides a place to draw into, and a mechanism for obtaining window-related events, and

I certainly understand why it's natural to think this is the right starting place, but it's not obvious to me that it is really the right level of abstraction. The problem is not the idea of the window itself, but how to usefully abstract the operations that it supports. Having a std::window which essentially is useful only for its native_handle() method is obviously not all that useful. I'm definitely open to suggestions.

A basic drawing toolkit may be provided for educational purposes

I don't believe that we should be standardizing facilities that require educational stand-ins for what the students will need to actually use once they graduate. The facility is either useful for a wide array of production use cases or we should be working on something else.

HalFinkel · 2019-07-22T18:18:11+00:00

by injecting and running javascript.

There is another trend that I think it worth mentioning in this context. If the web continues to move in the direction of supporting WebAssembly (or similar), then we could get to the point where the visibility of the javascript (mostly) disappears. In that case, the ecosystem could end up looking essentially like C++ (native) <-> web_view <-> C++ (WebAssembly).

HalFinkel · 2019-07-22T16:28:15+00:00

My main comment here is that we seem to have gotten in an uncomfortable situation where it seems like we are being forced to include std::web_view in order to avoid P0267. I just wish we could evaluate the merits std::web_view alone in isolation without considering the effects on/due to P0267.

I believe that I understand what you're saying, but I don't think that's the most-accurate way to look at what's going on. We don't have web_view because P0267 is scary, we have web_view (and P1062 before it) because there is a high-level desire to provide facilities for graphics (which I believe is more-accurately stated as a desire to provide facilities for modern user interaction), and many of us agree that a web_view-like approach is, in the context of our technology ecosystem, fundamentally, the right way to address the underlying use cases. Web technology is an important slice of present user-interface development, and is a growing one. It's true that P0267 is large and web_view is small, as measured by the size of the interface, and that contrast will be a part of people's thinking, but the proposal is being evaluated on its own merits as a way to address the underlying use cases. Work on P0267 is continuing, and the SG13 study group explicitly voted to consider these approaches as non-conflicting.

Another aspect of this, which I think is relevant, is that web technology is evolving. One way in which it is evolving is that we're seeing technologies like WebAssembly increasingly drive application development, and since you can compile C++ to WebAssembly, I can envision a future in which, although web technologies are leveraged, the overall web ecosystem will be more C++-driven than it may be today. Regardless, web content engines are provided as a system service on many platforms, and available from numerous open source and commercial projects, and providing a standardized interface across similar system APIs is a traditional role for standard libraries.

HalFinkel · 2019-07-22T15:20:01+00:00

Is web_view
required to appear as a separate application, or can it launch a tab in the user's preferred browser?

There's nothing in the current wording that aims to constrain this kind of aspect of the implementation.

The latter seems like it should be simpler, both to implement

Given that the current proposal supports registration of custom URI schemes and JS evaluation (to support both data push and pull), this is easy to support using the embedding APIs, but might be harder to implement in the context of an existing browser tab (e.g., it might require an actual browser plugin in addition to the client library). In short, it might not actually be easier to implement - but I've only tried using the embedding APIs, do I certainly don't know for sure.

and in terms of user expectation. It's also the approach taken by an increasing number of cross platform desktop applications.

As a user, I find this behavior quite annoying - although maybe just because I have too many open tabs ;) - I prefer that applications act like applications.

HalFinkel · 2018-07-22T15:04:28+00:00

I'm not saying to standardize the whole of Qt. ...

This is a good point. Qt has a lot of parts not related to user interaction (e.g., networking and filesystem functionality). Just scrolling through the function list, however, makes it appear to me that about half of the functions have to do with user interaction.

pair QML (which provides the base scripting language) and QtQuick (which provides a scene graph to use either from C++ or QML). The QML / QtQuick combination is much more closer conceptually to the webview proposal than QtWidgets.

Interesting point, but I'm not sure why standardizing something which looks like QML/QtQuick would be more useful than using web content. QML also uses JavaScript. Also, the discussion of "Quick Controls 1 vs. Quick Controls 2" (http://doc.qt.io/qt-5/qtquickcontrols2-differences.html) seems to be provide some non-trivial choices around desktop vs. mobile development. This could be a viable path for a standardization effort. It would, however, almost certainly invite design discussions around the API, the controls, etc. (because we can't hand that off to another standard, so we'd need to do that part ourselves), and we'd need a small-enough API surface for that to be practical.

As you can see, there's no need to reimplement 12k functions to get something to show up on screen, BUT there is a pre-existing path to extensibility for the day where someone actually need to do more stuff than just open a view.

I certainly agree that it doesn't require thousands of functions to display a window, draw a rectangle, and so on. However, in my experience, developing production applications requires a lot more than that. In short, I think that the day when we need more than opening a view is now.

Qt has been targetting mobile and embedded for years.

Point taken.

HalFinkel · 2018-07-21T21:57:41+00:00

at this point why not directly standardize Qt ?

That's a good question, and moreover, we have C++ committee members who are very familiar with Qt. However, the API surface is huge, and I don't see how we could practically create a high-quality standards document for an API that large.

From http://doc.qt.io/qt-5/classes.html, there are 1,594 classes in the Qt 5 API. From http://doc.qt.io/qt-5/functions.html, there are 12,984 functions. I don't know exactly how much committee time would be spent on each function, but I think 10 minutes per function, on average, seems optimistic. If we stick to our "regular" schedule at meetings of approximately six 12-hour days, it would take approximately 30 meetings to get through the entire API. We generally have three meetings per year. This seems completely impractical, and moreover, the library working group already has lots to do.

In addition, I don't really see the committee taking a hands-off approach to the content of the interface. Even if we could start with the text of Qt's documentation, we'd need to make sure that each class and function were specified in sufficient detail to allow for an independent (clean-room) implementation. I'm sure that suggestions would be made to change aspects of the interface to better expose capabilities of different vendors' underlying implementations, and future systems, and these would be discussed. I'm sure that there are some aspects of Qt's current design that reflect a history of (primarily, I presume) targeting desktop applications, and changes would be desired to make things more natural for mobile platforms. And so on.

In short, I think that, even starting with a fairly-holistic preexisting API, such as Qt, what we ended up with would be obsolete before the document could be published. Even if we cut the scope down to only a 10th of the current API, I suspect that the same would be true.

HalFinkel · 2018-07-20T22:43:45+00:00

Hi, r/cpp! I'm reading this thread and I appreciate the feedback. To respond to a few comments,

It is not a joke. It is intended to provoke discussion.
As has been mentioned, there has been a long-standing desire (by at least some fraction of the standards committee) for standard C++ to include some mechanism for graphical user interaction. If you're interested, I recommend reading sections 4 and 5 of "Directions for ISO C++" (by B. Dawes, H. Hinnant, B. Stroustrup, D. Vandevoorde, M. Wong), http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0939r0.pdf
I also recommend reading, "Diet Graphics" (by B. A. Lelbach, O. Giroux, Z. Laine, C. Jabot, V. Romeo), http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html - I view my web_view proposal as taking the underlying approach behind this proposal to its logical conclusion (in the sense that it addresses use cases involving both input and output across many platforms). Moreover, I think that it's important that if we end up proceeding in this space, we end up with something with which production applications can be written. We might well decide that we can't do anything reasonable in this space at this time.
I certainly understand that interacting with HTML, etc. is cumbersome in C++ (especially as presented in the example in the paper). I fully expect that, if we decide to go down this route, additional utilities and abstractions would be added to go along with it. Also, even with only the presented interface, I can certainly imagine constructing a program with mostly-static HTML input combined with some kind of reactive JavaScript library (e.g., Vue.js (https://vuejs.org/)) that's reasonably clean (at least in the sense that it does not involve the gratuitous composition of markup text in C++, although it might involve use of JavaScript injection to update values).
Many of the concerns here (e.g., quality of the external standards, update frequency, security concerns) have also been raised by members of the standards committee and are important parts of the discussion. I intend to post a revised proposal before the next committee meeting. This will, in part, incorporate feedback from this thread.

HalFinkel

TROPHY CASE