To what extent
that??™s an issue depends on both the reader and the initialization expression involved.
If you??™re explicitly calling a constructor, it??™s always going to be pretty obvious what
type you??™re creating. If you??™re calling a method or using a property, it depends on how
214 CHAPTER 8 Cutting fluff with a smart compiler
obvious the return type is just from looking at the call. Integer literals are another
example where guessing the inferred type is harder than one might suppose. How
quickly can you work out the type of each of the variables declared here?
var a = 2147483647;
var b = 2147483648;
var c = 4294967295;
var d = 4294967296;
var e = 9223372036854775807;
var f = 9223372036854775808;
The answers are int, uint, uint, long, long, and ulong, respectively??”the type used
depends on the value of the expression. There??™s nothing new here in terms of the
handling of literals??”C# has always behaved like this??”but implicit typing makes it easier
to write obscure code in this case.
The argument that is rarely explicitly stated but that I believe is behind a lot of the
concern over implicit typing is ???It just doesn??™t feel right.??? If you??™ve been writing in a Clike
language for years and years, there is something unnerving about the whole business,
however much you tell yourself that it??™s still static typing under the covers.
Pages:
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413