[cfe-dev] [RFC] Preliminary patch to support MSVC __declspec(property)

[endlessroad1991 at gmail.com]

On Thu, Dec 13, 2012 at 4:23 PM, John McCall <rjmccall at apple.com> wrote:

> On Dec 12, 2012, at 11:45 PM, endlessroad1991 at gmail.com wrote:
>
> Thanks, that's a very detailed and thorough comment.
>
> MSDN page for __declspec(property):
> http://msdn.microsoft.com/en-us/library/yhfk0thd.aspx
> we can declare "array-like" property:
>         __declspec(property(get=GetX, put=PutX)) int x[][];
> and access it with indices:
>         var = obj->x[expr1][expr2];
> it will be translated into:
>         var = obj->GetX(expr1, expr2);
>
> And that's what "ParamCount" in "PropertyAttr" is for.
> We don't know how many params until we parse to "int x[][]", so we have to
> modify the Attr when we get here.
>
>
> That documentation says you can declare this as "int x[]" and it permits
> an arbitrary amount of subscripts, but apparently you can *also* add
> multiple []s.  It would be good to understand the requirements and
> limitations of this language feature as implemented in MSVC.  In particular:
>
> 1.  Can you directly template these declarations? (template <class T>
> _declspec(property) T foo;)
>
No

> 1a.  Are any of the following answers different if T is dependent, and if
> so, are those likely to be bugs or actually intended?
> 1b.  What if you have template <class T> struct A { _declspec(property) T
> foo; }; and then instantiate the template at T=int[]?
>
Yes, this works fine.

> 2.  What's the relationship between []s and the number of indices?
> 2a.  Given _declspec(property) int x[], can you in fact use multiple
> indices with it, like foo.x[2][3]?
>
No

> 2b.  If so, what happens if the "element type" is itself subscriptable?
> 2b.i. _declspec(property) std::vector<int> x[] and foo.x[0][1]?
>
No

> 2b.ii. _declspec(property) int *x[] and foo.x[0][1]?
>
Yes, this works fine.

> 2c.  Do parentheses change these answers at all?
> 2c.i. _declspec(property) int* x[] and (foo.x[0])[1]?
>
Yes, this works fine.

> 2c.ii. For that matter, given _declspec(property) int x[], is (foo.x)[0]
> legal at all?
>
Yes, this works fine.

> 2d.  Given _declspec(property) int x[][], can you use fewer subscripts
> than that?  Can you still use more?
>
Answer for both questions is NO.

> 2e.  Just to verify, what happens if you subscript _declspec(property) int
> x;?  (no brackets at all)
>
No

> 3.  Are there restrictions on the element type?
> 3a.  Can it be a reference?
>
Yes

> 3b.  Can it be a bounded array type?  (_declspec(property) int x[][10])
>
No. Seems that whatever you put in the brackets will be ignored, and
treated as a param to getter/setter.

> 3c.  Can it be an unbounded array type if you use, e.g., a typedef?
>  (typedef int intarr[]; _declspec(property) intarr x;, or intarr x[] for
> that matter.)  Does this change the behavior of subscripting?
>
Surprisingly, in this situation, the [] in intarr is still interpreted as a
param to getter/setter.

> 3d.  Do parens in the declarator affect any of this?
>
No

> 4.  What exactly does the element type do there?  Is it just for
> type-checking the property against the accessors?
> 4a.  I'd been assuming that the accessors were selected by overload
> resolution at access time using the name given/inferred in the property
> attribute.  Is this not true?  Are they selected/filtered by initial
> type-checking somehow?
>
It is true. You can define "T GetV(int, int)" and "T GetV(double, double)".
And getter will choose the best match like normal overload functions.

> 4b.  Is access control checked on the accessors from the declaration point
> of the property or from the use point?
> 4c.  Can the accessors be inherited from base classes?  Are normal
> ambiguity controls enforced?  Can you scope-qualify the accessor names,
> e.g. get=Base1::getElt?
>
Inherit: yes. Ambiguity: yes. Scope-quailify: No, seems that there can only
be one identifier after get= or put=.

> 4d.  Are the index types in the accessors limited in some way, or can they
> be e.g. arbitrary class types?
>
They can be arbitary types.

>
> I'm sure we can find more questions. :)
>
> Considering this situation, is it still possible to do it in your
> suggested way?
>
>
> Sure, that's not really a problem.  One very important thing — something I
> seem to have unconscionably forgotten put in my initial review — is that
> this is way, way more than just a property on a FieldDecl;  this really
> needs to be some new kind of Decl, probably named MSPropertyDecl.  That
> node would then be a reasonable place to stash things like the expected
> (minimum?) number of indices and any other important information from
> type-checking the declaration, e.g. the possibly-filtered lookup results.
>  You'll probably need to recognize the presence of the attribute in the
> parser and enter into a completely different Sema entrypoint, kindof like
> how the 'friend' keyword does.
>
> John.
>


Based on answers of these questions, let's guess how VC implements property.
I think the design principle for them is, reuse existing compiler code as
much as possible, and make the solution as simple as possible.
Here are my opinions:
1. Any [], [10], or [] that comes from typedef, is treated as a param to
getter/setter. Hence, they lose their origin semantics meaning.
2. For accessors, they will be translated into getter/setter.
    i. property can be private, as long as getter/setter is public, they
work well.
    ii. getter/setter will be chosen like any normal overloaded functions.
3. property are treated like normal members. So they can be inherited, and
have ambiguity problem when a class has multiple base classes.
The only problem here, is when the element type is subscriptable itself.
    i. When it's pointer type, subscripting the property works as expected.
    ii. When it's class type which has overwritten operator[] (no matter
vector or self-defined class),  subscripting the property doesn't compile.
I can't guess why this happens.

-- 
Best Regards, Tong Shen (沈彤)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121214/a407a9ab/attachment.html>