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

[John McCall]

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;)
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[]?
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]?
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]?
2b.ii. _declspec(property) int *x[] and foo.x[0][1]?
2c.  Do parentheses change these answers at all?
2c.i. _declspec(property) int* x[] and (foo.x[0])[1]?
2c.ii. For that matter, given _declspec(property) int x[], is (foo.x)[0] legal at all?
2d.  Given _declspec(property) int x[][], can you use fewer subscripts than that?  Can you still use more?
2e.  Just to verify, what happens if you subscript _declspec(property) int x;?  (no brackets at all)
3.  Are there restrictions on the element type?
3a.  Can it be a reference?
3b.  Can it be a bounded array type?  (_declspec(property) int x[][10])
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?
3d.  Do parens in the declarator affect any of this?
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?
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?
4d.  Are the index types in the accessors limited in some way, or can they be e.g. arbitrary class 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121213/0b620da2/attachment.html>