I'm all for C# getting more expressive, but what it calls "Pattern Matching" simply is not the same thing as real honest-to-goodness Pattern Matching.
C# "Pattern Matching" is little more than destructuring, or switch, on steroids.
Much like how the compiler assists you when writing subclasseses so that you've implemented all the required methods, real Pattern Matching (F#) gives you the same guarantees from the compiler that you've handled all the possible cases appropriately.
This makes real F# pattern matching much more useful than "switch with destructuring", and helps you grow your programs in a safe way.
The C# way has all the same problems as the switch statement, which gives no feedback about what cases you've handled.
So, what we're seeing here is not necessarily the final stage. It's what we get in this release of the language, but more will likely follow.
The other one we'll never see: Non null references as a default, optionals as a special case.
I'm using LinqPad for all kinds of one-off scripting jobs and loving it. I was trying to learn PowerShell for that task but I've finally given up on that. PowerShell has some great features, but the overall chaotic syntax just kills me.
It still needs a project file, but it has a nice command line interface, which means you don't need VS.
But I'll probably still keep using LinqPad anyway.
Either way, neither of them run "true CSX files", but their own homegrown format that predates csx. But it has made me hopeful for the future of C# scripts.
Out parameters are bad, even with the improvements in C# 7. They're simply the Wrong Way to do multiple return values.
In almost all my projects I have extension methods like this:
public static V TryGetValue<K,V>(this IReadOnlyDictionary<K,V> dict, K key, V @default = default(V))
{
if (dict == null)
throw new ArgumentNullException(nameof(dict));
V result = default(V);
if (!dict.TryGetValue(key, out result))
return @default;
return result;
}
There are also a lot of old methods using Type arguments and requiring a cast where a generic alternative is really overdue.
Edit: Of course, some Optional<T> type would also be nice for the dictionary example, but since C# has null-coalescing and null-conditionals since version 5/6, the above example suits almost all my use cases, and can be used in a Maybe Monad-style way anyway.
Still I agree with you and fear that this will result in developers using out parameters other places because - "why not?".
Anyone know why it doesn't start with Item0?
At the time, we picked one based indexing because we felt it sounded more natural when spoken allowed (mirroring saying something like: This is the first Item in the tuple).
I would expect that the design bled over into ValueTuple, which looks very similar to the reference version, except, of course, it is a value type.
Out parameters are going to make some things much nicer. I can certainly see local functions being useful as well.
Out of all of it, I think the thing I'm most excited about is pattern matching. Having used F# for a short time, that was the biggest stand-out feature; it really does make some code much more concise and expressive.
I love C# but lately I've been using Python for my quick-and-dirty work because in general I find it to be more expressive. It seems like C# 7 might make me reconsider.