Ideas for C# 5.0 | Tech Off

exoteric
I : Next

What would you like to see in C# 5.0?

exoteric
I : Next

I'll start out -

Tuple Syntax
a la (precise parenthesization not so important here)

(1,2,3)

Tuple Enumeration

Not a language feature but allow tuple to be enumerated (IEnumerable<T>) for both homogeneous and heterogeneous tuples, meaning these two cases would both be legal

foreach (var x in (1,2,3))
Console.WriteLine(x);

foreach (var x in (1,"WTF",3))
Console.WriteLine(x);

Where in the first case the tuple would be IEnumerable<int> and in the second case the tuple would be either IEnumerable<IDynamic> or IEnumerable<Object>.

Bass
Channel 9, best used in moderation

In reply to exoteric

#Oct 18th @ 12:23 PM

BigInt literals

var bigint = 349438474346346348348346734634634892390139328234746546348349349347237236465483932948565623893832932932737;

staceyw
Before C# there was darkness...

In reply to Bass

#Oct 18th @ 5:04 PM

Not sure that would make the cut without a suffix literal. But something like a "B" suffix would seem to fit.

joechung

Range literals, e.g., 1..10 instead of Enumerable.Range(1, 10)

ManipUni
Proving QQ for 5 years!

In reply to Bass

#Oct 18th @ 5:04 PM

I cannot tell if this is sarcasm... Sad

TommyCarlier
I want my scalps!

In reply to exoteric

#Oct 18th @ 12:23 PM

I would be against tuple enumeration. A tuple is not a collection and should not be considered as such. If you really want that feature, you could build it yourself:

public static class TupleExtensions
{
  public static IEnumerable<T> ToCollection<T>(this Tuple<T, T> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
  }
  
  public static IEnumerable<object> ToCollection<T1, T2>(this Tuple<T1, T2> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
  }

  public static IEnumerable<T> ToCollection<T>(this Tuple<T, T, T> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
    yield return tuple.Item3;
  }
  
  public static IEnumerable<object> ToCollection<T1, T2, T3>(this Tuple<T1, T2, T3> tuple)
  {
    yield return tuple.Item1;
    yield return tuple.Item2;
    yield return tuple.Item3;
  }
  
  ...
}

exoteric
I : Next

In reply to TommyCarlier

#Oct 19th @ 3:28 AM

A tuple is a collection. It's just a heterogeneous collection where elements do not always have the same type. That said, using extension methods for tuple enumeration could be a pretty good midpoint between no support and built-in support.

SlackmasterK
I write my OWN blogging engines

REPLs. The demo just left me wanting for the days of BASIC on my TRS-80 when the command-line (if you can call it that) and the code felt interchangeable. Doesn't seem all that useful, but really fun.

stevo_
Human after all

I think first class tuples would be useful, I would imagine extension properties make it in as its been noted that they actually agreed on a specification for how to do it, just had to cut it for 4.0 in order to shipit.

Not sure about enumeration, a tuple is only a sequence in a syntactic sense, theres plenty of contexts for how you can iterate something, and I think there needs to be proper thought into what should be considered a native sequence to the language.. best bet is, does it really add anything? no, then its not worth introducing additional behavior.

wkempf

In reply to exoteric

#Oct 18th @ 12:23 PM

I'll agree with tuple syntax, but the (1, 2, 3) stuff isn't the important part. What's much more important is tuple assignment.

int a, b, c;

(a, b, c) = TupleReturningMethod();

exoteric
I : Next

In reply to wkempf

#Oct 19th @ 7:04 AM

I'll buy that for a dollar. I really liked that way of "decomposing" a tuple when using SML. Both are ways to make programs shorter because ultimately you don't need it, just as you don't need foreach.

TechChaser

I Would love to have partial publishing facility in website model applications, if there is an ASP.Net release

stevo_
Human after all

In reply to TechChaser

#Oct 19th @ 8:13 AM

I think this thread is specifically about language features, in terms of .net features, I'd love to see some work put into making compilation more extensible (like postsharp for example)..

daxfohl

In reply to stevo_

#Oct 19th @ 8:32 AM

Yeah, it would be interesting to see an application go through some programatic transform before compilation. Something a bit more powerful than the simple #if(DEBUG) ugliness. Maybe along the lines of a Linq to Parse Tree, or Linq to Assembly, or Linq to Attributes. ie, you could have your precompiler set up with a set of Linq expressions, and if you wanted to do a core compile, you would choose the one that removed all the [UI]-decorated classes and methods.

That would also allow a lot more flexibility for encapsulation and information hiding than the current five access specifiers, and would enable things like friend classes without explicitly adding friend classes. ie, the Linq code could specify that classes decorated with [Tester] would have access to all methods decorated [Testable], but that no other classes would be able to see it. That would allow the "architects" to create the attributes and write the Linq code to determine what is visible to what, while the application programmers simply create classes to work within those boundaries.

Something like a formal, compilable version of a standards document.

Another nice thing about doing things this way is that you gain the power of doing macro-type stuff, but since everything is just a Linq-to-Parse-Tree, it would be analyzable realtime to the editor and intellisense (just like the #if(DEBUG) is now).

Minh
WOOH! WOOH!

I want to have "endif"

Bass
Channel 9, best used in moderation

In reply to staceyw

#Oct 18th @ 6:48 PM

There is no suffix literal for Int32 and Int64, try doing a var on a literal over 3 billion in value, the compiler will automatically define it as an Int64.

TommyCarlier
I want my scalps!

In reply to Bass

#Oct 20th @ 9:56 AM

var i = 123L; // the type of i is long/Int64

exoteric
I : Next

In reply to Minh

#Oct 20th @ 9:52 AM

Is this a serious suggestion?

Bass
Channel 9, best used in moderation

In reply to TommyCarlier

#Oct 20th @ 10:53 AM

I ment to say that the compiler can figure out if a literal should be an Int32 or Int64 based on it's size. My bad.

contextfree

In reply to stevo_

#Oct 19th @ 4:51 AM

IIRC they decided the specification was the wrong thing and to go back to the drawing board.

exoteric
I : Next

In reply to stevo_

#Oct 19th @ 4:51 AM

It adds composability (direct use of tuples for LINQ) - but you're right, it needs to be thought out if there are costs involved, conflict cases - and whether to only allow it for homogeneous tuples: for this case what would be wrong, I don't see anything.