[Development] Converting types in Qt

[Poenitz Andre]

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.

[...]
> > > 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.

> 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.

Andre'