Ideas for C# 5.0

To illustrate

public struct STuple<a>
{
    private readonly a x;
    public a Some
    {
        get { return x; }
    }
    public a this[int index]
    {
        get
        {
            if (index != 0)
                throw new IndexOutOfRangeException();
            else
                return x;
        }
    }
    public IEnumerator<a> GetEnumerator()
    {
        yield return Some;
    }
    public static int Index
    {
        get { return 0; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Some
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public dynamic this[int index]
    {
        get
        {
            if (index > Index || index < 0)
                throw new IndexOutOfRangeException();
            else
                return index == Index
                    ? Some as dynamic
                    : Rest.Some as dynamic;
        }
    }
    public IEnumerator<dynamic> GetEnumerator()
    {
        yield return Some;
        yield return Rest.Some;
    }
    public static int Index
    {
        // C# forbids: (Rest.Index + 1)
        get { return 1; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}

Example

var a = new STuple<int>(3);
var b = new STuple<int,int>(1,2);
foreach (var x in a)
    Console.WriteLine(x);
foreach (object x in b)
    Console.WriteLine(x);
Console.ReadKey();

If we could somehow express a version of GetEnumerator that only applies to a homogeneous (s)tuple, meaning (s)tuple where all type parameters are equal, then there would be no need for a dynamic formulation, esp. as this is statically known.

public static class STupleExtensions
{
    public static IEnumerator<a> GetEnumerator<a>(this STuple<a, a> s)
    {
        yield return s.Some;
        yield return s.Rest.Some;
    }
}

I realize though that this kind of trickery is probably not very high on any wishlist heh

There are several things to consider. (The why is explained previously but see the end of this post as well (the questions)).

Types are shared across languages, imperative or declarative. The discussion here is about the formulation of tuples in .Net, so it is really language agnostic in a sense, it just so happens that C# is quite close to the lingua franca of .Net, MSIL. It could've been VB too for that matter. F# has a succint syntax but I'm not very convinced its fundamentally more functional than C# for example, given that C# now has lambdas and "monadic syntax". Both F# and C# are hybrid imperative/declarative/object-oriented languages; and F# has had to adapt to this as the .Net Framework is object-oriented (one possible interpretation of the dot in dot net?). So I don't believe a resistance to functional style C# is that meaningful in the larger scheme of things.

The experimental code provided here is just to show how tuples could be defined in a more "compositional" way. There is disagreement as to whether this is a good thing. That's good  and certainly does not discourage me from experimenting - I find this both educational and fun. C# or F#, it really doesn't make that much difference to me. Types are shared - the fundamental means of expression also.

So you should refocus your attention to the semantics: are tuples as sequences helpful or harmful; are tuples as structs vs classes helpful or harmful; are a "recursive" definition of tuples more helpful than a flat definition?

So let me boil it down to its absolute undeniable essence

STuple pros

- structs; for performance reasons (makes sense for tuples as most tuples are less than 10 elements)

- recursion; for composition (tuple.Rest rather than new Tuple<A,B>(tuple.Item1, tuple.Item2); to be fair: representation bias)

- enumeration; for composition (use tuples directly as sequences which, intuitively they are)

Tuple pros

- classes; for nominal typing (: INominal<T>)

- flatness; for ease of comprehension and simplicity

- non-enumeration; unmistakeable distinctness, no accidental application of abstraction

The tension here is somewhat like structural vs nominal typing. Is it a duck if it looks, walks and quacks like a duck or is it only a duck if it has duck painted over it?

These are choices. Being aware that there are choices being made for you and what the trade-offs are, is useful. I'm sure there are good reasons for the current design - nevertheless it is interesting to examine other paths of expression

(1) homogeneous tuples: Tommy already showed how you can enumerate them using extension methods. These are fully typed so no problem there. The next step is to define GetEnumerator as part of tuple itself and define it only for homogenous tuples -or- : given a foreach which would accept type-parametric extension methods, you could just define it as GetEnumerator<T, ...> extension methods.

static where possible

- nominal too!

(2) heterogeneous tuples; as mentioned previously, you can simply use dynamic. In this case you want to be extremely careful of course but you will not have to insert casts; in fact you may want this to be defined as extension methods from a nested namespace (System.Dynamic[.Tuple] or System.Tuple.Dynamic) so it isn't automatically imported; or even be able to except some extension methods for a particular variable... well ok, that's extreme

dynamic when necessary

- structural too!

The name Rest is not so important, although I like it (and it rhymes with Best - beat that!). Of course Rest could also be defined for tuples as they are defined today (Tuple<T, ...>), it just so happens it isn't. I wouldn't call a design bad because of a name but of course names are important in the final design; I've not picked the names with respect to a broader audience; such "streamlining" is not really interesting in the initial design phase, more of a distraction.

Two questions for you contextfree

- what is the -100 point test for C# (and how does it relate to any tuple syntax)

- how is enumeration of tuples equivalent to serialization

There is some elegance as well: auto-boxing and unboxing of values. <edit:wrong>On the other hand it is strange[1] that it's not possible to express that a struct (such as Tuple) conforms to an interface (such as IComparable<T>). Being a struct offsets you to a second-class[2] citizenship, stripped of priviledges such as interface inheritance.</edit:wrong>

Constness is really about purity as immutable objects lead to purity. Structs render mutability a tiny bit better as you always pass around copies but if a struct is mutable then it's still fundamentally impure and assists in permeating impurity; at least in an impure setting; say you have a method that has a local variable that is a struct type, then mutating this should be no major issue but if, on the other hand, this struct is not local but ambient in the object, then mutating it will affect purity of the object.

I believe D is working towards supporting notions of purity and the same with C# or maybe generally .Net in that I saw some special contract attributes for this somewhere (maybe).

It's interesting to think about having types be pure but also having a special purity constraint on types which the type-checker can enforce. This is the inverse of what Haskell does: everything is pure unless it's not - and then you get trapped in the IO monad. It would be quite nice to have a similar formalism, if reversed, for .Net, where you could express Pure<T>.

This would of course be a very special type, requiring compiler magic, depending on the power of the language itself; e.g. C# with a step in a multi-step compilation process for doing expression tree verification of static invariants such as purity; well, that's an advanced topic: allowing the programmer to extend the type-system/checker with arbitrary invariants; in a way we can think of contracts in this way too (it's just that many invariants can't be statically verified; but using types with more associated meaning would seem more powerful; somewhat like dependent typing perhaps.)

[1] Not strange in a pragmatic sense (language evolution takes time) but weird in an idiological sense (absent a notion of time, one could argue about imperfections such as unnecessary non-uniformity between structs and classes; on the other hand[3])

[2] Not a pun

[3]Talk is cheap

Thanks! I tried this a couple of weeks ago but misread the compiler output.

I would kick my own behind for this mistake but anatomy forbids it.

Inspired by the XHTML thread, this idea popped up; not new by any means but very much missing in action. First importing the members of a static class (Java people know this as static import; SML people as open; VB.NET people as something else)

public double Ex(double x)
{
    using Math;
    var z = 1/Sinh(x);
    ...
    return z3;
}

Next: importing the members of an enum

public enum HtmlChar : ushort
{
    nbsp = '\u00A0'
    ...
}
...
public void Output()
{
    using HtmlChar;
    var e = new XElement("p", ..., nbsp, ...);
    ...
    e.Save(...);
}

So two very different and very common scenarios covered by this (double-) feature.

[edit:] ushort does not work for Unicode in general, so have to switch to strings, which rules out enums

There doesn't appear to be anything special about Go's notion of type equivalence beyond structural typing. C# has dynamic now, not sure the good folks want to go beyond that because dynamic allows you to apply the same programming pattern but in a less type-safe way. Another idea is to be able to coerce a type that structurally matches a different type into that type - a sort of structural cast.

Love the idea behind persistent data structures.

Nonnullable<T> is not bad, it's close to the latin Nonnullus which looks and sounds beautiful. That said, personally speaking, there is an strange eerie funny attraction to Unnullable<T>. Anyway, that's naming...

Actually for non-nullability, we'd probably want two things

1. definition-site non-nullability annotation
2. use-site non-nullability annotation

And preferably we want these to be low-impact in terms of syntax.

Example 1: use-site non-nullability (ejecting null from the domain of Tuple<int,int>)

Tuple<int,int>! thouShaltNull = Tuple.Create(10,20);

Example 2: definition-site non-nullability (giving birth to a new type that is non-nullable)

public class Tuple<int,int>!
{
    ...
}

Example 3: use-site nullability of a reference type which is born non-nullable

UnnullableTuple<int,int>? thouMayNull = ...;

It will be forbidden to construct a combination such as

Unnullable<Nullable<Val>> ... // error
Nullable<Unnullable<Ref>> ... // error

where Val is some value-type (non-nullable) and Ref is some reference type (nullable); so that the inner type is born (un-)nullable and at use-site you create a double negation.

Same as

Val?! ... // error
Ref!? ... // error

It is also forbidden to create unnnullable+unnullable and nullable+nullable combinations.

Interesting idea. It looks like a more complete/holistic/uniform approach to type extension, kudos. It is reminiscent of partial classes, except not exclusive for classes. Now I wonder: if you have a partial class A and another partial class B in two distinct namespaces and say you have a simple console program and the console program imports partial class A; will partial class B then also implicitly be used or only if you explicitly import that namespace? In the latter case the partial class construct looks pretty darned close to what you want, except partial to classes, so to speak. Hindsight is great.

As for public/private, private is probably a sign of imperativeness because in an imperative setting you want to be careful about who's modifying your object using your special helper methods whereas when constructing new objects it's not really that big of an issue and this default looks wrong for a mostly-declarative world (or functional if you will). This will also save lots of code having to explicitly declare public all over. Well... too late for C#, that ship sailed long ago.

I'm not sure but on the face of it, it looks like your type extension idea would basically generalize and unite both partial classes and extension methods. Thumbs up. There may be gotchas but on the face of it, it looks very compelling.