Jon Skeet: Planning C# In Depth 2

Jon Skeet: Planning C# In Depth 2

  • Comments 8

Jon is asking advice about how to shape the second edition of his book “C# In Depth”. Jon, I like your current suggestions (in blue) about making tweaks to existing content and adding a new section on C# 4.0.

One thing I’d also love to see is a summary of the hypothetical C# vNext features that the community has been discussing in the blogosphere and on the forums. I think Jon is the right person to come up with a great summary of those features, the rationale behind them, and possible implementation (syntax).

Specifically, I’m talking about:

  1. Immutability (e.g. public readonly class) and related matters (initializing auto-props, using tuples as an implementation for anonymous types, making object initializers immutable, tuples in the language etc.). Also statically verifying immutability etc.
  2. yield foreach and allowing anonymous methods to be iterators (like a VB prototype that Paul Vick blogged about)
  3. return type covariance
  4. duck typing, making a type implement an interface without touching it’s source, techniques (TransparentProxy, Reflection.Emit etc)
  5. member-level var (hopefully we won’t have this)
  6. notnull, code contracts in the language
  7. traits/mixins (e.g. redirecting an interface’s implementation to a field/property that implements that interface)
  8. metaprogramming (syntactic/semantic macros, DSLs in the language, infoof, compile-time reflection, IL rewriting (PostSharp, CCI, Mono.Cecil), AOP, transformations, code generation)
  9. parallel programming, concurrency, etc.
  10. Am I missing something?
  • Going off of #5, you don't think type inference and generalization should get a boost in C#?

  • Don't forget the ?. operator: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=192177

  • MichaelGG: well, with var on type members you get the "butterfly effect" - one little change in the method body can have a tremendous solution wide impact - you can invalidate entire assemblies, break interfaces, etc. etc.

    See here for details:

    http://www.wilcob.com/Wilco/Articles/returning_var_from_a_method_in_csharp_3.0.aspx

  • That page didn't load so I can't comment on it specifically. But in general:

    1. Type inference will probably not work for "contract" type things like interfaces. I mean, where would the inference engine figure out the types for an interface? So at such points, you'll be explicitly typing things.

    2. The fact that type changes replicate is a good thing. If you change a type and the solution still typechecks, why is it bad? If it "breaks everything", then it simply won't build, so no harm done.

    3. Even with 1 and 2 considered, there is still tons of code that isn't a public contract, and as such, can have it's type change as needed. Ignoring this just because sometimes you have serialization or compat issues seems quite restrictive.

    4. Indeed, what makes C# seem so heavy to me is that I have to specify my types pretty much everywhere. That hurts refactoring (type signatures can easily be longer than some simple shared methods). Throw in the fact that I have to specify all my generic type parameters _and_ their constraints, and well, it's downright clunky.

    This isn't to say that the other points you mentioned aren't valuable. But without powerful generalization/inference, static typing has a ton of overhead.

  • Michael: agreed, I think you've got me convinced. All in all, if F# does it, then it's probably not that bad. And you still have the option of specifying types explicitly if you want.

    It's just a little var feature in 3.0 is still causing so much wars and debate (50%/50%) so I can barely imagine how disputed will its big brother feature be.

    In any case, I agree with what you wrote :) Let's leave it to the language designers now to see what they say :)

  • Also: generic constraints improvements (where T: enum, where T: delegate) also numeric operators on generics

  • Kirill, the operator constraints wouldn't be needed if #4 was done. (Not to mention operator constraints are pretty specific.)

    You could simply constrain the types to have certain members. But for performance, the CLR would probably have to have it. F# gets around this by inlining, but there's no reason the CLR couldn't inline at runtime instead. Well, no reason than it's a lot of work, probably :).

  • I forgot updating arrays to IEnumerable<T> everywhere (e.g. params IEnumerable<string> args), all BCL APIs with IEnumerable<T>

    Also need native C# syntax for IEnumerable<T>, Action<...>, Func<...>, Tuple<...> etc.

    E.g. string{} Foo instead of IEnumerable<string> Foo

Page 1 of 1 (8 items)
Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post