Hacker News Reader

Comment by bob1029 | Hacker News Reader

Out of everything in the new 5.0 release, I am looking forward most to the non-generic TaskCompletionSource. This is a primitive that has been bothering me for some time WRT tasks that return nothing. I've been resorting to using bool as the generic type argument and discarding the value in these cases.

Also, C# 9.0 is really cool. Will be abusing the new pattern matching stuff once we get a chance to upgrade. Looking like 3.1=>5.0 is going to be a non-event for us based on the current migration guides.

View on HN

I'm most excited for records and `with`. This is a feature in C# I've been wanting for years and will really help make the use of immutable data throughout a system easier with a ton, and I mean a ton, less boilerplate.

Shame 'with' will not apply to structs - all the ingredients are already there. Through it might be in the plan for some future release.

As I understand it, making structs implement the record stuff would potentially be...weird. But you're right, it'd be nice.

Speaking about the new records, it bothers me that the keyword in the class declaration is "data" but they call it "record". Why not just name it record? Or "value-data" or something more descriptive? Considering it's one of the biggest languages today, I'm assuming they have ton of people working on it, so I'm clearly missing something here. And why still call it a "class" in the code? Could just have been have keyword instead... So many questions

Is it data? It bothers me as well, but was not the latest blog post with the terminology record?

> it bothers me that the keyword in the class declaration is "data"

The keyword is the declaration is `record`. So you would write your record:

   record Person(string FirstName, string LastName);

Source: I am one of the language designers on C# :)

Huh, reading from https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/ which was the first hit on Google shows the following example:

    public data class Person(string FirstName, string LastName);

It seems https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh... is saying what you wrote above though.

Seems my previous comment was based on outdated/wrong information, I'm sorry and thanks for clarifying :)

Edit: Seems the post I wrote was published 20th May (probably written before) and that was the same date someone said the same thing as my comment here in the discussion about the "records" feature https://github.com/dotnet/csharplang/issues/39#issuecomment-...

Here is a more recent update on records with the new syntax.

https://devblogs.microsoft.com/dotnet/announcing-net-5-0-rc-...

Ha, I don't know if you worked on this but I had hopes when I saw you'd gone back that maybe we'd finally see records. I'd been seeing your name on record proposals forever.

Records are good, although in typical Microsoft style they've elected to call the new constructor syntax "positional" instead of "primary", and then subsequently failed to generalize the feature to normal classes.

With is just building on the anti-pattern where .NET programmers are too lazy to implement constructors.

> "With is just building on the anti-pattern where .NET programmers are too lazy to implement constructors."

What? And aren't records just a lazy way to make classes then?

The new with-expressions are a concession to the existence of initializers, which are themselves literally "stuff that should have been in the constructor" and are incompatible with immutability (hence the new init property hack).

The correct path would have been to require primary constructors for records as the only point of entry for data, declare initializers incompatible with primary constructors, and then just synthesize a method for creating copies - but hey, then you might as well just use Scala.

You seem to not appreciate the prqcticality of immutability in a large system.

Quite the opposite. My language of choice is Scala, which probably explains my frustration at Microsoft's consistent inability to do the right thing.

> I am looking forward most to the non-generic TaskCompletionSource

That has always seemed like a strange omission, but I can't say it's really caused me distress :)

Personally, I'm looking forward to the `half` type, the extra GC diagnostic info, improved app trimming, improved ASN and certificate handling, and of course the improved performance and increased reach of Span. But I think most of all, I'm looking forward to a long term plan and no more .NET Standard/Core mismatch.

The half type is going to be obsolete instantly. There are quite a few other new floating types becoming popular recently: bfloat16, TF32, etc

I wish they made C# support a notion of generic alrgebras.

> I've been resorting to using bool as the generic type argument and discarding the value in these cases.

After seeing other libraries do so, I've fallen into the habit of using a singleton 'Unit' or 'Empty' Type. (This technically also falls in line with the .NET conventions of DbNull.Value and Missing.Value)

Actually, typing that out, I wonder if we all should have been using Missing.Value all along? :)

Pity that `void` is so special in .net, instead of being a proper unit type (would have avoided the Func/Action duplication as well)

DBNull is my least favorite part of any version of any .net thing I've ever seen. I hate it with a fiery passion. It forces otherwise sensibly typed variables to be `object`, among a host of other sins.

idk. Null in an object versus null from the database could mean something different so DBNull makes sense.

Also, I don't see how you could say DBNull is responsible for forcing object on us. They could have just as easily made it a struct and i dont see what it would solve.

> Null in an object versus null from the database could mean something different so DBNull makes sense.

Fortunately, it's super easy to tell the difference. `DatabaseQuery()` vs `SomeOtherFunction()`. See?

> Also, I don't see how you could say DBNull is responsible for forcing object on us. They could have just as easily made it a struct and i dont see what it would solve.

Doesn't matter. Even if it was a struct, the only way to store both kinds of value in one variable is to declare it an `object`, even if it was a struct. `null` is a perfectly legal value for a `string` variable, but as soon as the possibility for some other null object (or struct) is raised, the target variable must be `object`. C# doesn't do unions (as a first class language feature anyway).

If you're talking about value types then nullable value types exist, which are still structs:

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

None of that helps. A nullable int is `Nullable<int>` or `int?` for short. There is nothing about the language feature that allows you to represent null with a totally different type like `DBNull`, other than declaring your variable `object`. What's the return type of a method that sometimes returns `int` and sometimes `DBNull`? It can only be `object`.

I seem to be having some trouble explaining my point. Maybe this will illustrate better. What should be the declared return type of this method?

    ??? GetValue() {
        if (condition) {
            return 7;
        }
        else {
            return DBNull.Value;
        }
    }

Why do you need to represent `null` with another type? Is this just an issue with DB query results? You can avoid it by making sure the query never returns null or read the values yourself using a type cast test:

int? someNumber = resultset.Records[0]["some_column"] as int?;

Somehow we've gone full circle, and you're arguing my position back to me.

That code sample is exactly how I'd write it. My only problem is that DBNull ever existed in the first place.

There's a difference in certain contexts between 'null' (i.e., a reader that is not initialized) versus DBNull (the value has been set as null by the db or something else). I still think its technically correct.

I get that it was annoying, but most of .NET before 3.5 was anyway. It's just nobody bothered to make the right syntactic sugar.

For callers that care about the distinction, there should (IMHO) have been a GetNullFlavor(). Personally, the number of times I've actually cared is indistinguishable from zero. But the number of times I've had to deal with the infectious stench of DBNull is higher than zero.

Yes, I have a point of view.

My point is that DBNull is only an edge case with DB queries. You can avoid ever dealing with it as I've shown or use an ORM like Dapper or Entity Framework that also handle it for you.

There's really no reason why you have to touch DBNull at all.

I really wish that were true. DBNull is in third-party libraries. And first- and second- too. Check out this code. Dot net really wants me to use DBNull. No database in play at all.

  var dt = new DataTable();
  dt.Columns.Add("name", typeof(string));
  //dt.Columns.Add("count", typeof(int?)); // NotSupportedException: DataSet does not support System.Nullable<>.
  dt.Columns.Add("count", typeof(int));
  var row=dt.NewRow();
  row["name"] = null;
  //row["count"] = null; // ArgumentException: Cannot set Column 'count' to be null. Please use DBNull instead.
  row["count"] = DBNull.Value;
  dt.Rows.Add(row);

Yeah I definitely miss having an Option<T> or Result<T> type in C# like F# has.

I also don't like that DBNull and Missing are reference types, it would be better to use a value type for this to avoid having to do null checks similar to Nullable<T> but I guess in this case it doesn't matter since they are used for different purposes.

Reply on news.ycombinator.com