[Development] Converting types in Qt

[Jędrzej Nowacki]

On Wednesday 16 of July 2014 08:41:07 Poenitz Andre wrote:
> Olivier Goffart wrote:
> > > > I'd say yes, for sensible conversion
> > > > You are right that it is a behaviour change, but i think it is worth
> > > > changing it.
> > > 
> > > Why?
> > > 
> > > On one hand you promise binary compatibility. On the other hand
> > > behaviour changes are proposed to be done on an "nice to have"
> > > base?
> > > 
> > > Do we really think that's ok to disallow changing some int foo() {
> > > return
> > > 42; } to some int bar() { return 42; } that's easy to discover at build
> > > time, but it's fine to change int foo() { return 42; } to int foo() {
> > > return -1; } ?
> > 
> > It's always a dilemma. We have to look at how likely we are to break
> > applications and I don't think adding a conversion is likely to cause
> > breakages.
> 
> Type safety is a safety net that catches errors very early in the
> software production and deployment cycle, and one of the features
> that makes a programming language usable for the development
> of large applications at a reasonable pace.
> 
> Implicit type conversions kill type safety. This is widely recognized
> as a bad thing. In case of C++ some are "unavoidable" due to the
> C legacy, but e.g. for user-defined conversion operators we now got
> "explicit", _because_ people learned the hard way that implicit
> conversions are causing more trouble than wanted.

That is a controversial statement. There is many languages, that doesn't offer 
strict type safety and they are fine. Let's no go into this discussion because 
it would lead us nowhere.

> [...]
> 
> > > > We use common sense on a case by case basic.
> > > 
> > > I tend to believe the common sense in type conversion land is pretty
> > > close to "avoid to do it automatically, prefer to make it explicit".
> > > 
> > > Already now it's far too easy to make mistakes based on the "nice
> > > and easy" QByteArray -> QVariant -> QString conversions when
> > > accidentally writing QByteArrays into QSettings and reading QStrings
> > > back. There shouldn't be more of that.
> > 
> > What's the mistake here? Wrong encoding? Bad performances?
> 
> Wrong encodings under circumstances that are typically not present on
> the developers or test machines. Here the lack of type safety postpones
> a problem that would be immediately visible (and fixable) at compile time,
> to the time after the application has been shipped.
> 
> In the best case this "only" causes a bug report that needs to be handled
> "normally", i.e. needs triaging/fixing/integration (and hopefully is not so
> critical to require an immediate emergency release, but can be delivered
> with the next regular one). Worst case this could mean that the application
> is unusable in a larger part of the world. With or without someone reporting
> the problem.
> 
> This is a kind of "convenience" I don't need, and I pretty much prefer
> the inconvenience of having to spell out type conversions explicitly.

In this particular case I would blame QSettings API, which pretends that is 
able to handle everything while it is not. 

> > When one use QVariant, it is because we want to enjoy dynamic typing
> > and nice conversions.
> 
> I wholeheartedly disagree. Most of my QVariant uses are there because
> the Qt API requires me to use it, and I sometimes use it voluntarily for
> type-agnostic storage or transport of "things". But in those cases I never
> want to extract anything else from the variant than exactly the "thing"
> I put into it.
> 
> I _never_ (at least not intentionally) use QVariant as a kind of "magic
> converter bag" where I put something in and get something
> "conveniently" munged back.

Actually I agree, I believe that QVariant should be just a stupid container 
which allows you to transfer a data in type agnostic way, from one place to 
another. Well, during it lifetime it accumulated a bit of additional 
functionality, but I see that the discussion is floating in wrong direction. 
Let's not talk about implicit QVariant conversions, we have them and we can 
not remove them. We can add, as Olivier suggested qvariant_type_safe_cast to 
our API. Let's talk about QMetaType::convert and 
QmetaType::hasRegisteredConverterFunction,  instead are we allowed to change 
their behavior by adding / modifying conversions ?

Jędrek

> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development