From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38153)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1ZNxYM-000143-Lx
	for qemu-devel@nongnu.org; Sat, 08 Aug 2015 02:24:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1ZNxYH-0007Cv-Ga
	for qemu-devel@nongnu.org; Sat, 08 Aug 2015 02:24:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:38463)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1ZNxYH-0007Ck-BT
	for qemu-devel@nongnu.org; Sat, 08 Aug 2015 02:24:17 -0400
From: Markus Armbruster <armbru@redhat.com>
References: <1438703896-12553-1-git-send-email-armbru@redhat.com>
	<1438703896-12553-27-git-send-email-armbru@redhat.com>
	<55C5074D.7050803@redhat.com>
Date: Sat, 08 Aug 2015 08:24:14 +0200
In-Reply-To: <55C5074D.7050803@redhat.com> (Eric Blake's message of "Fri, 7
	Aug 2015 13:30:21 -0600")
Message-ID: <87y4hm8fht.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH RFC v3 26/32] qapi: Introduce a first class
	'any' type
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com

Eric Blake <eblake@redhat.com> writes:

> On 08/04/2015 09:58 AM, Markus Armbruster wrote:
>> It's first class, because unlike '**', it actually works, i.e. doesn't
>> require 'gen': false.
>> 
>> '**' will go away next.
>> 
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
>> ---
>
>> @@ -1039,8 +1040,7 @@ class QAPISchema(object):
>>  
>>      def _def_builtin_type(self, name, json_type, c_type, c_null):
>>          self._def_entity(QAPISchemaBuiltinType(name, json_type, c_type, c_null))
>> -        if name != '**':
>> -            self._make_array_type(name) # TODO really needed?
>> +        self._make_array_type(name) # TODO really needed?
>
> Do we really want to allow ['any'] in schemata?  That would imply the
> possibility of a 2D array.

It's 2D-by-trickery.  Unlike the existing trick of wrapping the inner
array in a struct, this one isn't visible on the wire, though.  It
requires giving up some type checking.

>>From a backend point of view, array of any type should just work.  We're
already debating whether we want them under PATCH 02, so let's continue
there.

>> +++ b/tests/qapi-schema/qapi-schema-test.json
>> @@ -83,6 +83,8 @@
>>    'returns': 'UserDefTwo' }
>>  { 'command': 'user_def_cmd3', 'data': {'a': 'int', '*b': 'int' },
>>    'returns': 'int' }
>> +# note: command name 'guest-sync' chosen to avoid "cannot use built-in" error
>> +{ 'command': 'guest-sync', 'data': { 'arg': 'any' }, 'returns': 'any' }
>>  
>
> In particular, if we DO want to allow it, this file should be enhanced
> to include ['any'] in the UserDefNativeListUnion.

Yes, to keep the test case complete.

> As it is, JSON allows mixed-type arrays, but all our uses of QList are
> fixed-type (all elements share the same type); allowing an array of any
> element may prove to be problematic.

anyList is fixed-type, too: the fixed type is QObject * ;)

['any'] isn't ABI until we actually use it in an external interface.