Re: [Development] QtCS 2017 QtCore sessions
On 4 December 2017 at 21:29, Allan Sandfeld Jensen wrote: >> > I believe the name "optional" comes from Haskell and Java where it >> > appeared >> > first. The standard library only imports things that are already industry >> > standard, and once there were several implementations of optional out >> > there, they started to pull one in. They just didn't manage to write it >> > without using C++17'isms. >> >> std::optional has no fundamental c++17isms in it, and can be written >> without any problem in C++11 code. >> I maintain optional in libstdc++, in case you wonder on what basis I'm >> making that statement. > I know it can be written with C++11. I have both seen it, and done it myself. > I was just noting the C++17 version takes advantage of C++17 (which makes > sense). I did not mean to imply you couldn't or hadn't. I am sorry if I > formulated that wrongly. Right; stylistically, the C++17 specification uses C++17 facilities when convenient - that has nothing to do with what the committee "manages" to do or not. For optional, it uses, for example, the _v trait-value variable templates, which are C++17, but are perfectly possible to express with the longer-hand form with ::value. Beyond those, optional doesn't do anything C++17-specific (and was in fact implemented *and specified* in terms of C++14 when it was experimental::optional, and even there, the only C++14 facility it used was relaxed constexpr, but again, those things can be written with C++11 constexpr). Under the general as-if rule, implementations can and do implement optional with equivalent facilities that were there since well before C++17. >> The standard library imports a whole host of things that aren't always >> industry standards. but it imports things only when there's a proposal >> to import something. > > For this part I was refering call for proposals http://cplusplus.github.io/ > LWG/call-for-library-proposals.html which says it strongly prefers things > based on existing practice. Yes, *prefers*, but doesn't *require*. Even the ISO guideline of standardizing existing practice is a recommendation, not a hard requirement. > Anyway. I was just taking offense at Marc's claims that Qt was "stealing from > C++" by adopting similar compatible ideas as the standard library, but made > available for our supported platforms in our time frame. It made little sense > to me, as you might as well argue Qt is stealing from Windows and Mac, by > making a cross-platform toolkit implementing their established practices. I think Marc's concern is adopting e.g. an optional-like type and giving it a *completely* different interface because we prefer camelNames to std_like_names, which is migration-wise, generic-programming-wise and interoperability-wise a complete dead end. This leads to a discussion we need to have at some point, which is that if we write a Qt facility that's expected (no expected-related puns intended) to have an equivalent facility in the standard, we should give such facilities a standard-like interface with standard-like naming, instead of following our usual naming conventions. Same goes for semantics. Which brings us back to the discussion on constexpr on QStringView - it hurts migration and interoperability if string_view has constexpr operations that are not constexpr on QStringView. Having said that, there are nuances there, like *how much* it hurts and what kind of migration/interoperability. General design principles can have engineering exceptions, when the rationale for such is sufficient. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
On Montag, 4. Dezember 2017 15:30:49 CET Ville Voutilainen wrote: > On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: > > On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: > >> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the > >> Haskell name is maybe. So why is it QOptional and not QMaybe? Because > >> the C++ interface is used as the basis, not something from Haskell. > > > > I believe the name "optional" comes from Haskell and Java where it > > appeared > > first. The standard library only imports things that are already industry > > standard, and once there were several implementations of optional out > > there, they started to pull one in. They just didn't manage to write it > > without using C++17'isms. > > std::optional has no fundamental c++17isms in it, and can be written > without any problem in C++11 code. > I maintain optional in libstdc++, in case you wonder on what basis I'm > making that statement. I know it can be written with C++11. I have both seen it, and done it myself. I was just noting the C++17 version takes advantage of C++17 (which makes sense). I did not mean to imply you couldn't or hadn't. I am sorry if I formulated that wrongly. > The standard library imports a whole host of things that aren't always > industry standards. but it imports things only when there's a proposal > to import something. For this part I was refering call for proposals http://cplusplus.github.io/ LWG/call-for-library-proposals.html which says it strongly prefers things based on existing practice. Anyway. I was just taking offense at Marc's claims that Qt was "stealing from C++" by adopting similar compatible ideas as the standard library, but made available for our supported platforms in our time frame. It made little sense to me, as you might as well argue Qt is stealing from Windows and Mac, by making a cross-platform toolkit implementing their established practices. Best regards 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT printing via CUPS (advanced printing dalog box missing)
On 4 Dec 2017, at 15:16, Albert Astals Cid mailto:albert.astals@kdab.com>> wrote: El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va escriure: On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: This bug has been reported on QT ( see https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a year and half now, the bug status is still *reported* and the resolution *unknown*. I am sorry to post this information here, but we are many users affected by this bug and we are desperate because we don't have any feed back from QT. Is there anybody working on it ? No, there is not. The module is currently orphan, with no maintainer. Reviews more than welcome https://codereview.qt-project.org/#/c/213391/ https://codereview.qt-project.org/#/c/213390/ https://codereview.qt-project.org/#/c/213389/ https://codereview.qt-project.org/#/c/213388/ https://codereview.qt-project.org/#/c/213387/ https://codereview.qt-project.org/#/c/213386/ https://codereview.qt-project.org/#/c/213385/ https://codereview.qt-project.org/#/c/213384/ https://codereview.qt-project.org/#/c/213383/ Thanks a lot, Albert. I'll try to have a look in the next couple of days (or find someone else to do so ;-) Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
On Monday, 4 December 2017 06:00:53 PST Marc Mutz wrote: > Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the > Haskell name is maybe. So why is it QOptional and not QMaybe? Because > the C++ interface is used as the basis, not something from Haskell. FYI, I wrote QMaybe some 9 to 10 years ago, when D-Bus was discussing having maybe types. https://dbus.freedesktop.org/doc/dbus-specification.html#idm423, see "Reserved for a 'maybe' type compatible with the one in GVariant, and must not appear in signatures used on D-Bus until specified here" Since it didn't happen there, it didn't happen for us either. > Alex Stepanov also agrees that vector may not have been his wisest > naming choice for a dynamic array container, but it's still QVector, and > not QArray, after all And QList is not a linked list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
04.12.2017, 17:31, "Ville Voutilainen" : > On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: >> On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: >>> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the >>> Haskell name is maybe. So why is it QOptional and not QMaybe? Because >>> the C++ interface is used as the basis, not something from Haskell. >> >> I believe the name "optional" comes from Haskell and Java where it appeared >> first. The standard library only imports things that are already industry >> standard, and once there were several implementations of optional out there, >> they started to pull one in. They just didn't manage to write it without >> using >> C++17'isms. > > std::optional has no fundamental c++17isms in it, and can be written > without any problem in C++11 code. > I maintain optional in libstdc++, in case you wonder on what basis I'm > making that statement. > The standard library imports a whole host of things that aren't always > industry standards, but > it imports things only when there's a proposal to import something. See also https://github.com/akrzemi1/Optional/blob/master/optional.hpp > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: > On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: >> >> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the >> Haskell name is maybe. So why is it QOptional and not QMaybe? Because >> the C++ interface is used as the basis, not something from Haskell. >> > > I believe the name "optional" comes from Haskell and Java where it appeared > first. The standard library only imports things that are already industry > standard, and once there were several implementations of optional out there, > they started to pull one in. They just didn't manage to write it without using > C++17'isms. std::optional has no fundamental c++17isms in it, and can be written without any problem in C++11 code. I maintain optional in libstdc++, in case you wonder on what basis I'm making that statement. The standard library imports a whole host of things that aren't always industry standards, but it imports things only when there's a proposal to import something. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: > > Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the > Haskell name is maybe. So why is it QOptional and not QMaybe? Because > the C++ interface is used as the basis, not something from Haskell. > I believe the name "optional" comes from Haskell and Java where it appeared first. The standard library only imports things that are already industry standard, and once there were several implementations of optional out there, they started to pull one in. They just didn't manage to write it without using C++17'isms. The other name that sometimes gets used instead of Optional is Nullable (from SQL and C#), but that is a little different. I don't think "maybe" ever gets used much for this kind of type. Anyway. I do believe we should try to be compatible with std. I just don't see the point in throwing our hands in the air and refusing to improve our base classes while waiting for something we might be able to use 9 years from now. Btw. One of the issues with std::expected and std::outcome is that many are pushing for them to become C++ versions of Haskell monads, which complicates things. Best regard 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT printing via CUPS (advanced printing dalog box missing)
El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va escriure: > On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: > > This bug has been reported on QT ( see > > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a > > year and half now, the bug status is still *reported* and the resolution > > *unknown*. > > > > I am sorry to post this information here, but we are many users affected > > by this bug and we are desperate because we don't have any feed back > > from QT. Is there anybody working on it ? > > No, there is not. > > The module is currently orphan, with no maintainer. Reviews more than welcome https://codereview.qt-project.org/#/c/213391/ https://codereview.qt-project.org/#/c/213390/ https://codereview.qt-project.org/#/c/213389/ https://codereview.qt-project.org/#/c/213388/ https://codereview.qt-project.org/#/c/213387/ https://codereview.qt-project.org/#/c/213386/ https://codereview.qt-project.org/#/c/213385/ https://codereview.qt-project.org/#/c/213384/ https://codereview.qt-project.org/#/c/213383/ Cheers, Albert -- Albert Astals Cid | albert.astals@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
On 2017-12-03 22:57, Allan Sandfeld Jensen wrote: On Samstag, 2. Dezember 2017 17:48:19 CET Marc Mutz wrote: If that analyis were true, you'd need to explain why it is, then, that the Qt containers now have more or less the same API as std ones, when in Qt 1 they were very different. And why I keep needing to fight off QOptional. These are ideas that do not come from Qt. They come from C++/Boost. What are you smoking? Nothing, atm. I did a cigarette once, though, after some scotch. Didn't end all that well... These come from ML/Haskell who have had types like that for decades. Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the Haskell name is maybe. So why is it QOptional and not QMaybe? Because the C++ interface is used as the basis, not something from Haskell. Alex Stepanov also agrees that vector may not have been his wisest naming choice for a dynamic array container, but it's still QVector, and not QArray, after all (IIRC, it actually _was_ QGArray in Qt 1). So, seems Qt's using C++ as a reference. As it should (whenever Java was used, things went bad: QList, QListIterator, ...). For better or worse, Qt is a C++ framework, so it's important to not try to invent new names for all things C++. Thanks, Marc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.10.0 RC3 out
Hi, We have released Qt 5.10.0 RC3 today. Delta to RC2 as an attachment. With my current knowledge this should be now final Qt 5.10.0 content which we are planning to release this Thursday (if all still ok according to tests). Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. br, Jani qt5.10-rc2-delta-rc3-commits Description: qt5.10-rc2-delta-rc3-commits ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Branch request: wip/webassembly in Qt Declarative
Hi, We currently have a WIP branch in Qt Base for the WebAssembly work, but it turns out that we will also need changes in Qt Declarative that significant enough that it would be good to keep them in a WIP branch until we merge the feature back. No CI needed. -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfe...@qt.io http://qt.io The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
