5 ms·
Wow! They seem to be adding lots of the things that make Python feel more convenient than C#, tuples being big. Out parameters are going to make some things mu
by nxc18 10y ago
Wow! They seem to be adding lots of the things that make Python feel more convenient than C#, tuples being big.
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.
- vvanders 10y agoHappy to see that tuples are value types too. Very nice stuff.
- e28eta 10y agoAs someone unfamiliar with C#, it's strange that the default tuple element names start numbering at 1 (Item1, Item2...) Anyone know why it doesn't start with Item0?
- tintoy 10y agoPerhaps it's because they're item numbers, not indexes? As far as I can tell, C# uses 0-based indexing because most similar languages use 0-based indexing.
- icecube 10y agoIt has to due with history. Traditionally, other languages (such as Scala, Haskell and ML) with statically typed tuples start at index 1 instead of 0.
- e28eta 10y agoThanks! It stood out to me because Swift uses 0-based, and I suppose I either forgot or never used it in my brief exposure to Haskell & ML.
- ellism 10y agoFor what it's worth, I'm the one of the folks that designed the original tuple class (the reference type, System.Tuple, that shipped before hand). 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.
- dep_b 10y agoOne feature F# has that would be great is that you can declare primitives as a a type. So you won't mix up your kilometer floats with your miles floats. And kilometers divided by hours ends up being a km/h value. The other one we'll never see: Non null references as a default, optionals as a special case.
- amenghra 10y agoIn java world, there has been some discussion for something similar: https://jcp.org/en/jsr/detail?id=363 https://jcp.org/en/jsr/detail?id=363
- d--b 10y agoThey specifically avoided that in the early days of designing the language. Typedefs, macros, meta-programmation, overloading operators like () or -> are common in C++ but lead many people to completely change the language. So much so that there are C++ codebases that cant be read by standard C++ developers. The C# guys avoided that pit. As a C# developer I can read any codebase and know what's happening. That's not so true in F# where people are prompt to create their own operators (like ||>) and types.
- oblio 10y agoOperators, I get, but what's wrong with creating your own types?
- profquail 10y agoThe F# ||> operator is provided by the core library. Over-use of custom operators is something I always push back on in F# codebases; they can sometimes be useful in making code more expressive, but the downside is it makes the code significantly more difficult to comprehend until you're familiar with what each operator does. I prefer readability over concision, and even without the custom operators F# code is fairly terse.
- macca321 10y agoI'm hope it will come. In the meantime, you can always create a wrapper type, or use something like the ValueUtils nuget package.
- platz 10y ago> 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'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.
- int_19h 10y agoIt started its life as full fledged pattern matching, but there were just too many things there to cram it in a single release. If you look at proposals and discussions on Roslyn GitHub issue tracker, you'll see the backstory. 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.
- platz 10y agoYep, I'm aware of the backstory, and the additional planned keywords. I'm reacting mostly to the continued usage of the term for this release without those features, because those being introduced to the term for the first time, won't understand there's supposed to be a difference (and thus not understand the main arguments in favor of pattern matching).
- rattray 10y agoIs there another term that you think would be more accurate? "case-destructuring" or something?
- Pxtl 10y agoThe big impediment imho between c# and scripting language is the whole Visual Studio project experience. With Roslyn they introduced the csx format for c# scripts so you can have a stand-alone 1-file executable c# script, but the tooling hasn't caught up yet. 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.
- macca321 10y agoI think MS should buy LinqPad and give it away for free. It's just an amazing experience (having the full version is critical though).
- Pxtl 10y agoThere's a decent F/OSS implementation called CShell (bad name, I know, that's already a thing) http://cshell.net/ http://cshell.net/ 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.
- macca321 10y agoAnd another called RoslynPad
- sljd 10y agoThere can be some confusion between pipeline syntax and imperative syntax in Powershell, custom objects don't help either (i.e. `{...}` works differently than `[pscustomobject]{...}` for many cmdlets), but I'm curious what you consider chaotic enough to give up?
- RyanHamilton 10y agoFYI if any java developers are looking for a one file script running environment checkout http://jpad.io/ http://jpad.io/ I made it to scratch my own itch. It lets you run java snippets and view results as HTML even.
- NoGravitas 10y agoTuples and deconstructing assignment are the big thing for me. They are the way to provide for reasonable multiple return values. Out parameters are bad, even with the improvements in C# 7. They're simply the Wrong Way to do multiple return values.
- reitanqild 10y agoIIRC I saw an answer (from someone who seemed to know) last hear explaining that this was mostly about simplifying integration with code where this is common. Still I agree with you and fear that this will result in developers using out parameters other places because - "why not?".
- NoGravitas 10y agoAlso, "If they're adding new features to out parameters, they must be the hot new thing to use".
- btschaegg 10y agoOut parameters are bad, even with the improvements in C# 7. They're simply the Wrong Way to do multiple return values. I agree, but I fear that even with the new features, the according APIs will be missing for a considerable amount of time. It constantly surprises me is that MS has never bothered to update their old APIs with more modern methods; especally where out parameters are used for optional 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 is a considerable number of existing methods that would lead to sooo much nicer code if there would be some versions using modern C# features. In the case above, you can still use the original TryGetValue if there's no usable sentinel value you can use to distinguish "not found" cases from success. 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.
- alexc05 10y agoI actually did an involuntary fist pump when I saw "Tuples" listed. That feels like watching my preferred team score a touchdown in sports-ball.