[cfe-dev] [clang] declspec(property...) advice

[Eric Niebler]

(resurrecting this old thread....)

On 12/9/2010 5:16 AM, John McCall wrote:
> I'm a little worried about adopting our current representation for a
> C++-oriented feature.  Presumably we'd need to allow filling in default
> arguments, etc., plus a wide range of stuff that we technically have to
> support with ObjC++ properties but actually haven't gotten around to
> yet, like what happens when we're doing a compound assignment on an
> implicit property reference and the getter and setter have really
> different types.  Really I think this is an argument for improving the
> representation of all property expressions.

Indeed.

> My intuition here is to just rename OK_ObjCProperty to OK_Property
> instead of differentiating the two cases.  

Yes.

> It can mean "this is an
> entity which can be both read and written to, but requires special code
> to do so".  The existing hook in Sema for loads
> (ConvertPropertyForRValue) can easily be modified to handle the MS
> properties, and we can make BuildBinOp check for OK_Property LHS's and
> just immediately defer to some better hook.

And BuildUnaryOp for pre- and post-increment/decrement.

Doug, I've found a compelling reason why at least setter methods cannot
be resolved until the point of use. Consider:

  #include <cstdio>

  struct T {};
  struct U {};

  struct S {
    void setI( T ) { std::printf("T\n"); }
    void setI( U ) { std::printf("U\n"); }
    __declspec(property(put=setI)) int I;
  };

  int main() {
    S s;
    s.I = T();
    s.I = U();
  }

This prints:

  T
  U

Nasty, eh? I don't think the existing property stuff can handle this at
all, so like John, I feel this needs a major reworking.

Any and all suggestions welcome. This has become my #1 priority, and I
want to make forward progress quickly, but I want to do it right.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com