15

Huge proponent of using the 'var' keyword in C# for cases where it's very clear. For instance, rather than this...

ThisIsMyReallyLongFooClassName foo = new ThisIsMyReallyLongFooClassName();

I can type this...

var foo = new ThisIsMyReallyLongFooClassName();

...and I still have a strongly-typed variable. The two are, for all intents and purposes, equal. The latter is just more readable (again, because it's clear. There are cases where it isn't and 'var' shouldn't be used. I don't want this to become a discussion of that however.)

I'm wondering if Objective-C has anything similar.

Servy
  • 202,030
  • 26
  • 332
  • 449
Mark A. Donohoe
  • 28,442
  • 25
  • 137
  • 286
  • `var` is an implementation of "implicit typing". I've done a quick search but I can't find anything that states whether Objective C has implicit typing or not. A more extensive search might reveal the answer. – ChrisF Jan 12 '13 at 22:54
  • 1
    No, I don't think there is an equivalent. – Vervious Jan 12 '13 at 22:56
  • I don't see why you would use var in this example anyway? –  Jan 12 '13 at 23:00
  • Cleanliness of code. It's a preference, the same way some people prefer regions while others don't. Both can be (and often are) abused, but if they are used in a way that makes you more productive, then I think it's a good thing. – Mark A. Donohoe Jan 12 '13 at 23:02
  • 1
    This is called type inference. – Mechanical snail Jan 13 '13 at 03:21
  • __auto_type is the direct equivalent. You can #define var __auto_type and have much the same syntax as C# and Swift. – terriblememory Jan 09 '18 at 13:27

7 Answers7

14

Yes and no.

You can use id foo = ... which will always work, but you lose the type information.

If you really want something equivalent, you could use auto foo = ... from C++11, but then you have to compile your file as Objective-C++, which has many other side effects.

Convention is to just spell out your types; it's annoying, but unlike C++, C#, Java where templates/generics can make typenames very long, it's usually manageable in Objective-C.

cobbal
  • 69,903
  • 20
  • 143
  • 156
  • Actually, I've been mostly changing all of our O-C files to O-C++ files (by changing the 'm' extension to 'mm') because of all of the other benefits like overloading, more class libraries to work with, etc. We haven't found many problems in doing so. What 'side effects' are you referring to? If anything, this is just another reason to keep doing this. – Mark A. Donohoe Jan 12 '13 at 23:01
  • ...and I forgot to ask... what about when it would be SomeClass * foo = new SomeClass(); Is 'auto' smart enough to handle that it's a "pointer" (i.e. the asterisk. Yes, I know it's not s true pointer, but hopefully you know what I mean.) – Mark A. Donohoe Jan 12 '13 at 23:05
  • @MarqueIV There are things legal in C that aren't legal in C++. see http://stackoverflow.com/questions/10461331/what-are-the-incompatible-differences-betweeen-c99-and-c11 for lots of examples. Nothing really major, but things like void* requiring an explicit cast. – cobbal Jan 12 '13 at 23:08
  • More no than yes, implicit typing is absent in objective-c. – Ramy Al Zuhouri Jan 12 '13 at 23:09
  • @MarqueIV yes, auto is smart enough, objective-C objects are true pointers, and auto handles them just as well as it does any pointer. – cobbal Jan 12 '13 at 23:11
  • You know, I'm glad to hear you say they're true pointers! I have always felt they were and have gotten into arguments with other O-C users about that with them saying they were different than their C counterparts, to which I replied 'Then how can you legally store one in the other and vice-versa?' Their reply was about how you use it, but that is a language syntax distinction, but the underlying data is a pointer. Someone owes me a beer! – Mark A. Donohoe Jan 12 '13 at 23:14
  • Also, it's my experience that compiling the same file as O-C++ is slower than compiling it as O-C. This may not be true any more in the time of Clang, but it was definitely true back in the gcc/g++ days. – ipmcc Jan 12 '13 at 23:23
  • 4
    Objective-C object references are truly pointers, but they are *not* assignable through `void*` without potential problems (which is why ARC explicitly prevents void* conversion without expressing memory management intent). Many ObjC programmers -- myself included -- shun the use of ObjC++ exactly because of the complexity and side effects. Many of us do not consider operator overloading to be a feature. To each his own, just make sure your team is fully apprised of what is and is not off limits. – bbum Jan 13 '13 at 01:23
  • Actually, `auto` in Objective-C always deduces the type to be `id`. So that doesn’t work either. –  May 24 '14 at 09:06
  • How about `__auto_type`? – Pang Jul 31 '17 at 03:00
6

There is now, __auto_type. For example...

__auto_type test = @"Hello World";

...results in test having the type NSString*.

Here's a decent writeup:

https://medium.com/@maicki/type-inference-with-auto-type-55a38ef56372

The author suggests using

#define let __auto_type const
#define var __auto_type

in some shared header in your application to make the usage cleaner. I'm a bit wary of this kind of macro usage personally but I've been doing it for a while and the world is still turning... Maybe macro names less likely to cause a collision would be better.

terriblememory
  • 1,712
  • 3
  • 18
  • 25
  • Switched to yours for the answer since this now applies. BTW, personally I like using macros like that. Helps us who work in Swift and Objective-C daily. I'm a huge fan of doing such things provided you are matching parity between languages like that. – Mark A. Donohoe Jan 09 '18 at 16:16
5

No, there is no equivalent in Objective C. C++11 introduced the auto keyword to do it, but neither C nor Objective C has a similar capability.

The id is closest to C#'s dynamic keyword. It lets you achieve similar results to var, except that it does not let you access properties using the property syntax. It does let you invoke methods, including methods that implement property accessors.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
5

You can do something like this:

__typeof([obj someMethod]) foo = [obj someMethod];

That's ugly, but if you have a snippet or macro defined to automatically generate it, then you don't have to type out the type names. For example:

#define LET(V, EXPR) __typeof(EXPR) V = (EXPR)

LET(vc, self.viewController);  // equivalent to "UIViewController* vc = self.viewController;"
LET(d, [number doubleValue]);  // equivalent to "double d = [number doubleValue];"
LET(foo, [[Foo alloc] init]);  // equivalent to "Foo *foo = [[Foo alloc] init];"

Note: I'm not recommending this approach, as the convention in Objective-C is to write out the full type names or use id, and macros can be messy. But knowing about __typeof() can be handy.

Kristopher Johnson
  • 81,409
  • 55
  • 245
  • 302
  • Neat trick, but I already know about macros, and that doesn't really shorten things or make them cleaner like (I think) the 'var' keyword does. Still, thanks for the answer. – Mark A. Donohoe Mar 27 '14 at 00:37
4

There is the id keyword in Objective-C, but note that it is equivalent to the dynamic keyword in C# and not the var keyword. var is implicit typing - ie the type is inferred, but it is still static typing. dynamic and id are for dynamic typing and you lose type information.

manojlds
  • 290,304
  • 63
  • 469
  • 417
1

I am afraid that no such equivalent exists in Objective C which would allow you to preserve strong typing.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
0

You can use id keyword in objective C, but it doesn't work as c#

in c#

var stringVar = ...

stringVar worked as string variable and you can use access the string function by doing stringVar.function

id stringVar = [NSString ...]

but it still work as normal id type.

Machavity
  • 30,841
  • 27
  • 92
  • 100
Stay Foolish
  • 3,636
  • 3
  • 26
  • 30