[Development] RFC: Improved Q_ENUM

[Matthew Woehlke]

On 2015-02-18 12:14, Thiago Macieira wrote:
> On Wednesday 18 February 2015 17:44:05 Olivier Goffart wrote:
>> On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote:
>>> 1. How does this interact with QSettings? If I directly pass an enum to
>>> e.g. QSettings::setValue, is it written as an int or an enum (I guess
>>> int)? What about if I use QVariant::fromValue (i.e. so the variant type
>>> is the enum)?
>>
>> I have not tried QSettings yet, but since it works with QVariant it should
>> work.
> 
> But if already worked, this means the new file format will be different than 
> what it used to. We may actually have to keep the current format so old 
> applications can read the settings file produced by new applications.

(Did you mean to say that backwards? I would generally expect new
settings may not be compatible with old code...)

I'm not sure there is an issue here. If I do this:

  settings.setValue(key, enumValue);

...I think this relies on implicit conversion to int (because QVariant
can't construct from an arbitrary type without fromValue, correct?), and
so will (continue to) write a number. Even with Q_ENUM. Therefore, this
won't break.

Similarly, a QVariant with a "genuine enum type" was not previously
convertible (correct?), so anyone that is *using* fromValue to serialize
is also overloading the stream operators anyway, and in such case
probably will not switch to Q_ENUM (or at least will be aware of the
possible consequences of doing so).

IOW I don't think any existing code will change by accident just by
starting to use Q_ENUM.

(There might be a case for allowing conversion of QVariant with an int
to an enum, if the int is a valid enum value. For that matter, does the
other direction work? If I have a QVariant with an enum, can I get the
numeric value from that without knowing the enum type?)

-- 
Matthew