6 ms·
I think Declaration expressions are a mistake and proper support for tuples (and pattern matching) shold have been put in. It feels like an inbalanced expressi
by louthy 13y ago
I think Declaration expressions are a mistake and proper support for tuples (and pattern matching) shold have been put in. It feels like an inbalanced expression with the result on the left and the right:
var success = int.TryParse(s, out var x);
I'm a bit 'meh' about Primary constructors, Auto-property initializers, Getter-only auto-properties. It seems a bit messy and incomplete. Personaly I don't use properties anymore and just use readonly fields with constructor initialisation (which is enough to capture the property setting logic). What I would like to have seen in this area is 'readonly' classes, with mechanisms for cloning objects using named parameters for partial updates:
readonly class ReadOnlyClass(public int X, public int Y, public int Z)
{
}
Usage:
ReadOnlyClass obj = new ReadOnlyClass(1,2,3);
ReadOnlyClass newObj = obj.X = 10;
Instead of the current system for creating immutable classes in C#, which becomes quite unweildy and error prone as the number of fields grows.
class ReadOnlyClass
{
public readonly X;
public readonly Y;
public readonly Z;
public ReadOnlyClass(int x, int y, int z)
{
X = x;
Y = y;
Z = z;
}
public ReadOnlyClass SetX(int x)
{
return new ReadOnlyClass(x, Y, Z);
}
public ReadOnlyClass SetY(int y)
{
return new ReadOnlyClass(X, y, Z);
}
public ReadOnlyClass SetZ(int z)
{
return new ReadOnlyClass(X, Y, z);
}
}
Usage:
ReadOnlyClass obj = new ReadOnlyClass(1,2,3);
ReadOnlyClass newObj = obj.SetX(10);
I think 'using' static members will be a huge win for creating functions which appear to be part of the language. For example I use the following to do type inference on lambda expressions:
static class lamb
{
public static Func<T> da<T>(Func<T> fn)
{
return fn;
}
}
var fn = lamb.da( () => 123 );
I'v tried to make it look like part of the language by making it all lowercase, but it's still a little odd. Being able to 'using' a static class in would be perfect for this kind of stuff. To be used sparingly obviously.
Expression bodied members, yes please! So pretty...
public double Dist => Sqrt(X * X + Y * Y);
Typecase and Guarded Cases would be lovely too. Basically anything that enables expression based coding in C#. It would be nice if the LINQ language functions were extended too: count, take, skip, tolist. It's slightly less pretty when having to wrap the expression in brackets to call .ToList();
- Hakeashar 13y agoI would love to see pattern matching and at least some kind of tuple support. I don't know if it's ever going to happen in C# though... The `using` static is actually really good news. I have seen people who seem to be really mad about it, but sometimes it would be nice to have, for example: // Something like Scala's 'Predef' public static class Id<T> { public static Func<T, T> Identity { get { return x => x; } } } and then do: using Id; var grouped = list.GroupBy(Identity); Considering you can already open modules in F# (which are compiled down to static classes), it seems that feature found its way to C#. So maybe there is still hope for pattern matching and tuple support :) Equivalent of F#'s record types would be also awesome, which is what you put as 'readonly class': type Person = { FirstName : string; LastName : string } let single = { FirstName = "Jane"; LastName = "Doe" } let married = { single with LastName = "Smith" }
- louthy 13y agoAgreed on all counts . Not sure what the C# team's desire is for another classification mechanism (record types), but it could be seen as an opportunity to fix some of the problems of the past (mutable types, nullable object references). Perhaps C#'s record type could enforce immutability on not just the record but anything it's assigned to (maybe by using 'let'). That would allow the old mutable way to co-exist with language enforced immutability. It doesn't seem like it would clutter up or modify any existing code either, so if you don't like it, you never need to see it. Not sure how that would work when assigning to a class's member property/field. Perhaps you opt out of immutability (of the reference) with a 'mutable' keyword: class AClass { public mutable ARecordType Value; } Functional languages also 'extend' the behaviour of a type by defining functions that work with the type. But with an object-oriented language like C# you'd still expect the functionality to come with the type I think. So I suspect it would have to look something like this: type Vector { float X; float Y; float Z; int Length => Math.Sqrt(X*X+Y*Y+Z*Z); Vector Add( Vector value ) => new Vector { X+value.X,Y+value.Y,Z+value.Z }; } So it turns the entire class into one big constructor (with everything public by default). All non-expression fields should be provided when you instantiate the object: let obj = new Vector { X=1, Y=2, X=3 }; I'd be very happy with that. Maybe I'll fork the compiler and have a go... if I can just find the time.... gah