this post was submitted on 21 Jun 2023
14 points (100.0% liked)

C Sharp

1526 readers
4 users here now

A community about the C# programming language

Getting started

Useful resources

IDEs and code editors

Tools

Rules

Related communities

founded 1 year ago
MODERATORS
 

New features for those who haven't seen them:

// Primary constructors
public class NamedItem(string name)
{
    public string Name => name;
}

// Default lambda params
var IncrementBy = 
    (int source, int increment = 1) => 
        source + increment;

Console.WriteLine(IncrementBy(5)); // 6
Console.WriteLine(IncrementBy(5, 2)); // 7

// Type aliases
using Point = (int x, int y);
top 11 comments
sorted by: hot top controversial new old
[–] [email protected] 7 points 1 year ago (1 children)

Okay, I love these features individually. I loved it when moving from java to kotlin. However, I'm conscerned that these features create multiple ways to do things correctly in C#. Having one way to do things, has been for me one of the best features of C#. It makes it easy to read colleagues code accross generations and easy to onboard new guys.

I do hope we see these adopted quickly, but I hope the C# folks dot start shoehorning in new syntactic sugar for no good reason. The language is starting to get a bit arcane.

[–] [email protected] 2 points 1 year ago (1 children)

Any codebase of any complexity will invariably have its own way of doing things. As long as the dialects are mutually intelligible and using one doesn't make it harder for consuming code to use another, it's usually not a problem. I don't think these features are likely to cause these problems.

[–] [email protected] 2 points 1 year ago (1 children)

A codebase is different than the language itself enabling many ways to do the thing.

You may not think it's likely to cause problems, but have you actually onboarded non c# devs onto new C# projects?

I have been for the last 6 months and let me tell you it really opened my eyes to new problems. One of those is that there are many ways to do the same thing, which has been a consistent pain point for non-c# devs, and has been hurting adoption and general sentiment.

Honestly I didn't think much of it till now, and didn't think it would be that big of a deal. Turns out it is.

[–] [email protected] 0 points 1 year ago

Onboarding them onto... what? Out of the billions of possible standards and practices to adopt, you are either showing them which to use, or letting them pick. There is usually not a single right way to do something. This isn't exclusive to C#. Language features are only a tiny subset of the functionality a programming language is used to build.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (1 children)

In my opinion type aliases shouldn't use using keyword, since it is used by other useful features, but overall those changes are nice.

Yes, C# is slowly getting more bloated, like C++, but it's still a lot better than cpp imo and those changes (especially primary constructors) can remove boilerplate code.

[–] Perhyte 5 points 1 year ago

Type aliases already existed, and already used the using keyword. This version essentially just adds a few new options for the bit after the = (to be specific: tuple types, array types, pointer types, or other unsafe types).

[–] [email protected] 3 points 1 year ago (1 children)

I'm a bit confused about the point of tuple type aliases. I don't see a good reason to ever use

using Point = (int x, int y);

over

record struct Point(int x, int y);

I guess if you're working with something that expects a tuple or value tuple, this saves you an explicit conversion from your record type to a tuple.

[–] hurp_mcderp 1 points 1 year ago

Also, it's still a tuple so you could simplify existing code without breaking any extension methods you have on them by making a separate type.

It looks like this was added for flexibility and to make the aliasing system more orthogonal to the type rather than to fill a particular need but who knows.

[–] [email protected] 2 points 1 year ago (1 children)

Primary constructors I think are getting a bit too much bloat for the language. I get the purpose and I use them in Scala, but it just feels like too many ways to do a simple thing in C#.

Tuple type aliases FTW

Just still desperately hoping for Union types

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

I heard that unions won't be implemented in C# 12, unfortunately

[–] [email protected] 2 points 1 year ago

I heard the same. The number of places I want to use something like an Option<T> instead of having to consider null values… One day though

load more comments
view more: next ›