[Development] Converting types in Qt

[Jędrzej Nowacki]

On Tuesday 15 of July 2014 10:38:52 Poenitz Andre wrote:
> Olivier Goffart wrote:
> > Jędrzej Nowacki wrote:
> > >   1. Are we allowed to add new conversions?
> > >   
> > >      The question is tricky because adding a new conversion is a
> > >      behavior
> > >      change, as this code:
> > >      if (variant.canConvert(QMetaType::int)) ...
> > >      may work differently. If we add custom types into the mix,
> > >      everything
> > > 
> > > is even more complex.
> > 
> > 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; } ?

Yes. Because there are two separate issues here. One is that the "build time" 
sometimes doesn't exist, and you do not want to break an application that had 
no opportunity to rebuild. Second is that I'm not talking about abstract "foo" 
or "bar" function. I was explicit what would change, it would be Qt answer for 
a simply question "could you convert this value to this type". I guess in most 
cases the question would be placed in a context: "could you convert this value 
to this type, because I know only how to handle the type and not any other". 
In my opinion it is good to answer the question with "yes".

> > so Qt can know it and use it. For certain types we can do much better,
> > 
> > because we can automatically convert some types. For example:
> >          QVector<char> -> QLinkedList<int>
> 
> QVector<char> v; v.append(130);
> QLinkedList<int> l = /*some"Sensible"AutomatedConversion*/(v);
> 
> assert(l.first() == 130) ?  "Depends" ?

Invalid code = undefined output. You can simplify the example to:
 QVector<char> v; v.append(130);
 assert(v.first() == 130) ?  "Depends" ?
The issue has nothing to do with a magic conversion. You can blame C++ 
standard, which doesn't specify if char is signed or not, or people that write 
such code. I guess both options are valid :-)

> > >          A conversion may be arbitrary. For example, most of the
> > >          conversions
> > > 
> > > to QString. Should "bool(false) -> QString" return "False", "0",
> > > "false"?
> > > What about precision of, for example, "double -> QString" ?
> > 
> > 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".

You are right, it is good to avoid it, but sometimes it is not possible 
especially, if you do not control full stack.

> 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.
>
> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development