Open RuiCuco opened 5 months ago
CC @rjmccall @Bigcheese
As I understand it, @"string"
produces a CF string literal unless you pass -mno-constant-cfstrings
, which means that the object won't actually be of your class. ObjC is pretty lax as long as classes provide the same methods, but I don't think it's unreasonable for the compiler to not just assume that all string classes provide essentially the same methods. If you pass -mno-constant-cfstrings
, it should change the type of the string literal to the -fconstant-string-class
class.
As for your general point, I'd say Clang is open to patches that allow the compiler's use of the standard library to be configured. I'm not aware of anyone who's currently interested in doing that work, though.
I'm doing my own string class in Objective-C called 'kString'. If I compile the project with the compiler option '-fconstant-string-class=kString', I get the following warning:
clang shouldn't issue any warning because it works everytime I use the @"" literal. The pointer types are not incompatible: I tested it and it simply works! No warning needed!
By the way, how about implementing a similar mechanism for the other @ literals? I could say, for example:
and then compile with the compiler options '-fconstant-int-class=kInt' and '-fconstant-float-class=kFloat' to generate the correct code. Why am I asking you to go to all this trouble? Because it's coherent with the string mechanism mentioned above and because the Objective-C language should't expect anything from its libraries, no class names and no method names, as much as possible. That is, only the structure of data is important, like a string object being expected to have a 'Class isa', a 'char* cString', and an 'unsigned int length'. The rest should be at the programmer's discretion. It's good design, I think.