Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> On 11/21/19 9:07 AM, Markus Armbruster wrote:
>> Max Reitz <mreitz@redhat.com> writes:
>>
>>> With this change, it is possible to give default values for struct
>>> members, as follows:
>>>
>>>    What you had to do so far:
>>>
>>>      # @member: Some description, defaults to 42.
>>>      { 'struct': 'Foo',
>>>        'data': { '*member': 'int' } }
>>>
>>>    What you can do now:
>>>
>>>      { 'struct': 'Foo',
>>>        'data': { '*member': { 'type': 'int', 'default': 42 } }
>>
>> The '*' is redundant in this form.
>>
>> Can anyone think of reasons for keeping it anyway?  Against?
>
> Is there ever a reason to allow an optional member but without a
> 'default' value?  Or can we just blindly state that if 'default' is
> not present, that is the same as 'default':0/'default':null?
>
> Or, applying your statement further,
>
> 'data': { '*a':'int', '*b':'str' }
>
> is shorthand for:
>
> 'data': { 'a': { 'type':'int', 'default':0 },
>           'b': { 'type':'str', 'default':null } }

You propose to default 'default' to a type-specific value.

I don't think that's a good idea.

Quoting myself on v3:

    In many programming languages, absent optional arguments / members
    default to a default value specified in the declaration.  Simple.

    In others, 'absent' is effectively an additional value.  The code
    consuming the argument / member can interpret 'absent' however it wants.
    It may eliminate the additional value by mapping it to a default value,
    but it can also interpret 'absent' unlike any value.  If there's more
    than one consumer, their interpretations need not be consistent.  The
    declaration provides no clue on semantics of 'absent'.

    QAPI is in the latter camp.  I trust you can already sense how much I
    like that.
    [...]
    If I could go back in time, I'd flip QAPI to "'absent' defaults to a
    default value".  Lacking a time machine, we're stuck with cases of
    "'absent' means something you can't express with a value" and "'absent'
    means different things in different contexts" that have been enshrined
    in external interfaces.  Is there anything we could do to improve
    matters for saner cases?

    I think there is: we could provide for an *optional* default value.  If
    the schema specifies it, that's what 'absent' means.  If it doesn't, all
    bets are off, just like they are now.

This patch implements this idea.

When an absent member behaves just like it was present with a certain
value DFLT, we want to be able to say in the schema 'default': DFLT.

But the schema language also needs to let us say "absent member behaves
unlike any value".

If we define 'default' to default to a value, then that value must have
this special meaning.

Where that value is also a valid value, the schema language cannot
express "absent member behaves like it was present with that value".

I think this makes 0 a poor default value for 'default': "behaves like
member was present with value 0" is fairly common, I think.

Defaulting 'default' to null regardless of member type could work.

null is a valid value of the 'null' type and of alternate types with a
member of type 'null'.  For optional members of such types, the schema
language then can't express ""absent member behaves like it was present
with value null".  I think the need to say that is much less common than
the needs to say "like value 0".

Checking...  *sigh*: there are a few optional members that can take null
values, e.g. MigrateSetParameters member @tls-creds.  I read its doc
comment twice, and I have to admit I can't make heads or tails of it.
Can't say for sure whether absent behaves like null, or some other
value, or unlike any value.

QAPI/QMP introspection already specifies null to have exactly this
special meaning.

> So I could live with permitting '*' only in the shorthand form, and
> declaring that it is incompatible with longhand form because the
> existence of a 'default' key in longhand form is evidence that the
> member is therefore optional.

Noted.

More opinions?