[cfe-dev] objc++ enhancements for new c++ features

[John McCall via cfe-dev]

> On Mar 28, 2018, at 5:15 PM, James Gregurich <bayoubengalml at mac.com> wrote:
> 
> 
> 
>> On Mar 28, 2018, at 3:07 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>> I think we actually take the parameter as a pr-value, which in some ways is better because it means that you can pass something either by copy or by move.  I don't know if we then try to move-assign the ivar from the parameter, but we certainly should.
>> 
>> I think the more interesting question is the type of the getter.  The getter really can't return a && or pr-value.  Do we recognize that a type is move-only and just make the getter return a `const &`?  Does that mean we forbid synthesizing such a property as atomic?
> 
> 
> Let me focus on issues I encounter that make @property problematic or inconvenient. perhaps I'm misusing the tool.
> 
> 
> consider the code below.  What I want to be able to do is get a reference to the map instance variable and modify it. but the code doesn't compile because the property wants to return a  copy. 
> 
> 
> @interface AppDelegate ()
> @property (nonatomic, assign) std::map<std::string, int> prop;
> @end
> 
> @implementation AppDelegate
> @synthesize prop;
> 
> 
> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification
> {
>    auto& tmpP = self.prop;
>    tmpP["test"] = 1;
> }
> 
> 
> @end
> 
> 
> ok. so I try this... 
> 
> 
> @property (nonatomic, assign) std::map<std::string, int>& prop;
> 
> 
> but then I encounter the following that doesn't work...
> 
> self.prop = std::map<std::string, int>{{"test",1}, {"test2",2}};
> 
> and of course this doesn't compile...
> 
> 
> @property (nonatomic, assign) std::map<std::string, int>&& prop;
> 
> 
> The only answer I see here is to manually write the accessor functions and have an explicit instance variable declaration. I'd like to be able to use @property for convenience, but I see no way to make it work for what I naturally want.  is there an answer that isn't "don't use @property"?

I think this is a pretty poor match for @property, yes.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180328/f31c11aa/attachment.html>