I realize you may be waiting for 3.3.5 now, rather than have us thinking about Wt 4.0 but the recent cppcon (which we regretfully didn’t attend) inspired us here (at Emweb) to reflect on what could be the spark for Wt 4.0.
We quickly concluded the following list of things we would like to see for Wt 4.0:
Support c++11 (and later) only: no more support for c++03
Reduce reliance on boost (in favor of std)
Align with the C++ Core Guidelines in a pragmatic way
These things together should result in faster compile times
Fix some errors in our APIs that require a breaking change (most notably boost::any in WAbstractItemModels)
As you can see, functional changes aren’t per se on this list because we don’t see any functional change that warrants breaking the API, we have been managing these fine over the history of Wt with incremental updates.
It would be nice to hear your thoughts though (especially dropping support for c++03) on what’s included and what’s missing from this list!
Modeled after a now 20-year old library (Qt), Wt has never been, nor tried to be, a poster-child of modern c++. Admittedly, when Wt was created (I know realize we are celebrating a 10th anniversary in December!) c++11 wasn’t around the corner, and we did already make some choices (STL, standard library, boost) which made Wt less of an archaism than Qt is today.
But even then we more than happy to get our inspiration from what is probably still the best and consistent desktop UI toolkit around rather than experimenting with fancy new c++ features.
Today, it seems that after c++11, and c++14, with excursions in new complex features (move semantics, decltype, etc…), there’s a new focus on how to use all of this behind the scenes to allow programmers young and old create good software (nicely illustrated in the keynote of Herb Sutter). The goal clearly is to make c++ again an enjoyable language.
One of the main changes we foresee is to align with the core guidelines with respect to the preference for smart pointers over raw pointers. We believe that the strict ownership model of Wt (and Qt) is quite intuitive, mostly transparent, and gives few problems in terms of memory leaks or dangling pointers. But it would be nice to express transfer of ownership in APIs, as well as get exceptions rather than segmentation faults if one de-references a dangling pointer. In other words, we do not want to change the ownership model, but rather make it more clear and safe.
Another change that we are looking forward to is the removal of some arcane boost libraries that we’ve been dragging along for years. One such library is Boost.Signals (or Boost.Signals2), of which we use only a tiny portion, for the use-case in Wt, resulting not only in faster compile times (experiments indicated a factor of 2 should be feasible) but also faster code (for those that worry) and simpler stack-traces. Along the same lines, another choice that we have regretted since we understood it’s a bottleneck is the use of boost::any in our public APIs.
Specific non-goals are anything that make it harder to port over existing Wt 3 code to Wt 4 (although there will be a porting effort) without adding value: e.g. we will not exchange CamelCase for snake_style.
Before you ask: there’s no time-frame yet. At the moment we are gathering ideas and looking at technical constraints (such as our internal C++ Wt to Java JWt tool-chain).