31–40 of 278 posts
In F# these are "guaranteed" to be non-null, even though null instances come up during deserialization all the time. In C# use cases, I don't think the non-null "guarantee" should be made or implied, just a POCO.
This resulted in many cases that those methods needed to be broken out into their own class... which is the way to go some times but felt like a bit of overkill in others
Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same release. It's great to finally have tuples, but the c/java style syntax is showing it's age compared to something like scala which has return type declarations at the end, which I find much more readable. Literal improvements will be a godsend for writing database migrations. Ref returns and locals look li…
Dependency Order Compilation
Since C# is starting to look more like JavaScript (i.e. local functions) and vice versa (i.e. arrow aka lambda expressions). I'm going to throw my pocket change into a couple features I've been growing old hoping to see: 1. Regex expressions just like Regexp in JS: /^\s+$/.IsMatch(" "); // or Regex r = /^\s+$/; 2. DateTime expressions, similar to regex, something like: DateTime clockTowerLightning = #1955/11/12 10:04…
I don't know about the current state of C#'s grammar, but ambiguities between this regex construct and eg. division contributes to the complexity of correctly parsing JavaScript code.
https://tc39.github.io/ecma262/#sec-ecmascript-language-lexi...
I wish they did not call it pattern matching. Instead this is more like Destructuring combined with Switch. the guarantees are different
type Tree = Empty | Node of 'a * Tree * Tree
But that doesn't mean that C#-style pattern matching (really, Is-patterns and a Type Switch) don't fall under the umbrella of Pattern Matching. You can define tuple patterns that you can match on with the switch statement in C#, which is every bit a form of pattern matching as matching on a particular case of a union type.
Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same release. It's great to finally have tuples, but the c/java style syntax is showing it's age compared to something like scala which has return type declarations at the end, which I find much more readable. Literal improvements will be a godsend for writing database migrations. Ref returns and locals look li…
> Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same release.
Out variables are really great when working with existing code that predates Tuples (for example, the entire BCL). We don't just introduce language features that will only work well for new code. We also want to make the experience of coding against existing APIs feel better.
> Ref returns and locals look like a source of constant headaches.
That 'headache' has to be weighed against the needs of some parties to write very fast code and to have as little overhead as possible. ref returns enables a much more pleasant coding experience that enables these sorts of speedups in these specialized scenarios.
> It's much harder to reason with code when the data can be modified by random others bits of code.
There is a simple solution to this of course, don't expose your data through ref returns :)
For many (likely most) developers, ref returns simply won't be something that ever hits their radar. Similar to stackallocs and other esoteric features, this is really a targeted improvement for people who really like working in .Net but are finding it hard to squeeze out essential perf in some core scenarios.
The .net runtime supports this features fantastically. We wanted to make it available to people who like the power and safety of C#, but occasionally need some low level hooks to get that extra perf boost as well.
Pattern matching! Tuples! Awesome, C# 7.0 is scratching two itches I've felt every time I've worked with it. If only .NET had a suitable cross-platform UI toolkit, then I'd be using it everywhere. Eto.Forms is a good attempt but I found rather buggy and limited at this point in development. Avalonia, while further along in terms of stability and features, doesn't even try to fit in with any platform's look and feel.
Feels kinda crazy to see tuples and pattern matching "just arrive" when other languages have had them for years.
https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.1...
Since C# is starting to look more like JavaScript (i.e. local functions) and vice versa (i.e. arrow aka lambda expressions). I'm going to throw my pocket change into a couple features I've been growing old hoping to see: 1. Regex expressions just like Regexp in JS: /^\s+$/.IsMatch(" "); // or Regex r = /^\s+$/; 2. DateTime expressions, similar to regex, something like: DateTime clockTowerLightning = #1955/11/12 10:04…
My main objection is over the month/day confusion with other formats. Is that November, or December?
It looks like they've added a lot of rope to hang ourselves with typos. int myvar, I; foo(out int mvar); // oops, not myvar; maybe caused by a refactor? bar(out *); // oops, not I; was up too late coding And so on. Things like this would be easily missed when reading code at-a-glance, and it's this sort of bug that arises often in languages that allow implicit declaration of variants.
I don't really see your example in that way. Let's start with the latter one first:
> bar(out *); // oops, not I; was up too late coding
I'm not sure how this situation is any differnet from any other case where you need to pass some variable, and you pass the incorrect name. This is already possible all over the language. For example, you might have written "bar(out J)" when you meant "bar(out I)". As usual, the recommendations here are to use strong types and good names to help keep your code clear in intent and to allow the compiler to tell you when something seems awry.
Now let's look at your first example:
> foo(out int mvar);
This version immmediately screams at me that something is happening that requires my attention. First off, just the presence of 'out' is an immediate call that this is not a normal call. Nearly all calls pass by value, so out/ref stick out like a sore thumb (esp. in an IDE that classifies them accordingly). Second, the "out int" is another large indicator that this is doing stuff very special.
Finally, i'd point out that the mispelled name problem is really no different than what you might experience today with code like:
int myvar;
...
// much later and indented a bit ...
int mvar;
Foo (out mvar);
> it's this sort of bug that arises often in languages that allow implicit declaration of variants.
No implicit declarations are allowed. All declarations are explicit. We just don't force you to have to declare in one location and use in another. This is a pattern that many people hate, and which goes against a desire to immediately declare and initialize, and thus not have to track down how a variable is written to.