[Patch][ObjC][Proposal] NSValue literals

AlexDenisov 1101.debian at gmail.com
Fri Jan 9 13:42:20 PST 2015


Well, it's not a problem to implement such diagnostics, but I still see some disadvantages.
Here is my random thoughts:
NSEdgeInsets (and corresponding NSValue factory method) available for both iOS and OS X triples starting from 8.0 and 10.10 respectively. To get this error (or warning, doesn't matter) user need to compile his code with an earlier version of SDK, which means that NSEdgeInsets and corresponding method are not available there and compilation will fail earlier, it will be even impossible to create a variable of type NSEdgeInsets.
On the other hand I know a few projects/developers who is doing some backports by defining the same interface for the earlier SDKs by introducing the same classes and/or by extending existing ones via categories (personally I did this for NSArray/NSDictionary to add support of subscripting).
In case of these restrictions (errors/warnings) we'll add the barrier, which might provide more frustration than safety.

Another one disadvantage is that the code will be even more tightly coupled with NSFoundation and won't be as generic as it is right now, because of code like this:

  if (type == NSEdgeInsets) {
    if (triple.os == iOS && triple.version < 8.0) {
      emit_warning("unavailable on iOS");
    }
    if (triple.os == OSX && triple.version < 10.10) {
      emit_warning("unavailable on osx");
    }
  }

But, yes, it's just my opinion and the last word is yours :)
-- 
AlexDenisov
Software Engineer, https://github.com/AlexDenisov

On 9 Jan 2015 at 21:04:51, jahanian (fjahanian at apple.com) wrote:


On Jan 9, 2015, at 11:41 AM, AlexDenisov <1101.debian at gmail.com> wrote:

We may not support boxing of any pointer types after all 
(as the underlying API does not manage the collected object).
So, final patch may need to address that.
No problem. To be honest, I don’t see real benefits of having such ability, it was a silly decision to include this functionality (motivated by ‘because I can’).

Please provide more tests 
for NSEdgeInsets and specifically, see that diagnostics come out when 
deployment target does not support it.
What kind of tests should I add? It has tests for Sema and CodeGen, did I forget/missed something?



Test should show that if some one uses auto boxing for NSEdgeInsets in deployment targets that do not support it, a proper warning is
being issued. You may have this test already but I could not locate it.
- Fariborz


- Fariborz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150109/8f57b1f7/attachment.html>


More information about the cfe-commits mailing list