1

As apple Introduced a new syntax for array literal and dictionary literals:

NSArray* literalArray = @[@"1", @"2", @"3"];

//Dictionary Literal
NSDictionary* literalDictionary = @{@1:@"first", @2:@"Second", @3:@"Third"};

They are not behaving like String literals. My question is what can be the reason that they have not introduced NSCFConstantArray class similar to NSCFConstantString? What will be the drawback to introduce a new class except backward compatibility?

rmaddy
  • 314,917
  • 42
  • 532
  • 579
Saurav Nagpal
  • 1,247
  • 1
  • 10
  • 27
  • 2
    Did you try modifying any of these? Was your attempt successful? Look up `NSMutableArray` and `NSMutableDictionary`. – Sergey Kalinichenko Jan 08 '17 at 11:13
  • 1
    Precisely what string literal behavior are you looking for out of array literals? There's a ton of very specific memory stuff going on in `NSCFConstantString` that isn't nearly so applicable with collections. And, remember, just because you're dealing with array literal, it doesn't mean that everything in that collection is immutable. Or are you talking about having this `NSCFConstantArray` to only be used when everything in that immutable collection is somehow known to be immutable, too? Bottom line, what problem are you trying to solve with this `NSCFConstantArray`? – Rob Jan 08 '17 at 11:47

2 Answers2

3

This could have been implemented, but it probably wouldn't be very useful. For this to work everything in the array or dictionary would have to be a compile-time constant as well. This would be rather limiting - without any other changes you'd only be able to create arrays and dictionaries containing nothing but strings. The number literals are not compile-time constants either. Of course those could be implemented as compile-time constants too.

But this whole thing would not be very useful. Most of the time you use those literals to put some values only known at runtime into arrays or dictionaries. It's probably not worth to go through all the trouble to implement all that.

Sven
  • 22,475
  • 4
  • 52
  • 71
0

It would entail introducing additional "inappropriate" knowledge of specific Foundation classes into the compiler, tying it more closely to Apple's frameworks rather than being a general-purpose compiler.

For example, it might interfere with using the compiler with GNUStep rather than Cocoa.

The integration with NSString is long-standing and can't be removed now, but adding more such integration would have to have a really compelling argument for it.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
  • You wouldn't have to make the compiler know about foundation classes. The compiler could define a memory layout for those as it does for the string integration and it would be foundations turn to provide classes that have exactly that memory layout. Works the same for NSString - you can tell the compiler which class to use for string literals. – Sven Jan 08 '17 at 11:27