|
No, I get it. And that process isn't limited to C#.
|
|
|
|
|
C++ joined the chat
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Agreed!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Behzad Sedighzadeh wrote: ... recent addings to the language ...
I'm not convinced by your definition of "recent"! 
Behzad Sedighzadeh wrote: Named/optional arguments
Added in C# 4, which was released in April 2010.
Behzad Sedighzadeh wrote: ??
?[]
The null conditional / coalescing operators were added in C# 6 (July 2015).
Behzad Sedighzadeh wrote: discards
C# 7 (March 2017)
Behzad Sedighzadeh wrote: ()
Not entirely sure what you're referring to here. I'm going to guess that you mean value tuples, which were also added in C# 7 (March 2017).
Behzad Sedighzadeh wrote: Switch expressions
C# 8 (September 2019).
As with any addition to the language, nobody is forcing you to use them. If you want to stick to writing C# 1.0 code, then you're free to do so. It's only when you come to read someone else's code that you might need to understand the newer constructs - but even then, there are ways to convert the code to an older syntax.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
modified 7-Sep-22 3:26am.
|
|
|
|
|
I tend to agree with you on this one.
C# has always been innovating, for the sake of trying new things or simply taking a swing to solve minor issues.
I have no problem with Microsoft doing this. Most additions end up never being used in production anyway.
As far as I can tell, they typically serve a very niche purpose and audience, and only rarely catch on.
|
|
|
|
|
I think OP is only starting to see these in code bases.
Not everyone is on latest/greatest day 1  adoption takes time.
I have to also say something about "nobody forcing" is - try to write C# 1.0 code and get it past code review
In the end everyone will have to just put up with it - if they like these features or not.
|
|
|
|
|
No one is forcing you to use those new features unless you're working on a codebase that uses those new features.
Things like
public readonly double Distance => Math.Sqrt(X * X + Y * Y);
are, for me, a matter of taste. Things like
public static bool IsLetterOrSeparator(this char c) =>
c is (>= 'a' and <= 'z') or (>= 'A' and <= 'Z') or '.' or ',';
give me stomach acid. A dev has saved a few keystrokes at the expense of structure.
This
static Quadrant GetQuadrant(Point point) => point switch
{
(0, 0) => Quadrant.Origin,
var (x, y) when x > 0 && y > 0 => Quadrant.One,
var (x, y) when x < 0 && y > 0 => Quadrant.Two,
var (x, y) when x < 0 && y < 0 => Quadrant.Three,
var (x, y) when x > 0 && y < 0 => Quadrant.Four,
var (_, _) => Quadrant.OnBorder,
_ => Quadrant.Unknown
};
is meant to provide neat, compact code but I worry that for someone new to C# it becomes a stumbling block.
My feeling is that it should be easy to switch between languages. Truly I wish there were only one language, but us humans are tribal and so that will never happen (and of course situations where a language needs to have specifics for the platform, hardware, compiler or programming methodology).
Even so, making a language simpler is better, and adding syntactic sugar for the sake of it simply diverges the language.
In many instances adding new features can converge languages. Javascript gaining the coalesce operator, C# getting the null-check. This is All Good. But like good art, they should add what they need and no more.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
public readonly double Distance => Math.Sqrt(X * X + Y * Y);
That would give you a CS0106 compiler error.
You would need either:
public readonly double Distance = Math.Sqrt(X * X + Y * Y); or:
public double Distance => Math.Sqrt(X * X + Y * Y);
Chris Maunder wrote:
c is (>= 'a' and <= 'z') or (>= 'A' and <= 'Z')
Well, of course, anyone serious about performance would write that as:
(uint)((c | 0x20) - 'a') <= 'z' - 'a'
Source: Performance Improvements in .NET 7 - .NET Blog[^])
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
modified 9-Sep-22 3:38am.
|
|
|
|
|
|
|
The purpose of the "is" contruct with multiple conditions is to avoid repeating the first operand (imagine it is a function or method, or attribute whose evaluation or dereference would have a side effect).
Here it allows writing it, without having to declare and initialize the value of an additional local temporary variable (that temporary variable or register will be allocated/defined intrisicly by the compiler, and only where it needs it). You get a shorter and more readable condition with "is" than with such additional explicit declaration.
Then when testing "c is" with constants or ranges, this becomes very clear, and the compiler can choose how to represent the ranges or individual values (notably when they are constant) and generate the best code (yes it means that it can then optimize "c is (>= 'a' and <= 'z') or (>= 'A' and <= 'Z')" itself into "(uint)((c | 0x20) - 'a') <= 'z' - 'a'", but without using ugly expressions with unsafe/unchecked typecasts.
So in my opinion this short notation is a good idea, and it remains very readable while being safe (and allowing easier optimization and inlining if needed by the compiler).
Doing the same thing in C++ is a real nightmare (you have to play with very ugly "move" semantics that are very hard to debug when there are also multiple overriden candidates for operators/convertors/constructors and so many implicit typecasts to play with). Doing that in C is simpler, but hard to manage as the compiler has no knowledge or control of the semantics, so it cannot make so many optimizations: you need to use explicit local "register" declarations, put multiple statements within braces, possibly surrounded by the "do{}while(0)" trick when using ugly macros... And still the C compiler is unable to perform optimizations you'd expect (and there's no warranty that it works when you also have to play with "volatile" semantics), plus the effect of "restricted" state concurrency used by modern processors using multiple cores and modern architectures using caches over shared buses/networks, where loads/stores may be reordered.
Cosidering all this, the "is" construct is very safe and the compiler will generate the correct code while preserving all the needed semantics, and without pollutiong the source code with ugly temp varaibles and extra local scopes.
|
|
|
|
|
Be more positive - learn these additions, but use only if fits...
After all - they do not force you!!!
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
Gone are the days when you could sit back a read a "Command" manual. You need at least a browser.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: Be more positive - learn these additions, but use only if fits...
After all - they do not force you!!!
Nope, you're wrong. It's very easy to get in the position of supporting someone else's unreadable code.
Of the last 8 to 10 C# releases, I've found about 90% of the new syntax to either be useless or counter-productive, as it makes the code unreadable.
The C# team keeps making "additions", as it's their job, and for the most part they ran out of useful things to add years ago, but they don't let that stop them. 
|
|
|
|
|
Some of them are pretty useful. For example:
private void DroppedURL_DoWork(object sender, DoWorkEventArgs e)
{
if (sender is BackgroundWorker worker)
{
...
Makes code much cleaner than the traditional way:
private void DroppedURL_DoWork(object sender, DoWorkEventArgs e)
{
BackgroundWorker worker = sender as BackgroundWorker;
if (worker != null)
{
...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Umm ... is predates as, yes? as is intended as an improvement over is.
|
|
|
|
|
is with a built-in as is new though
|
|
|
|
|
|
Maybe under other names?
- is with "declaration pattern"
- Three-operand is
- C#7-is
|
|
|
|
|
Seems kludgey.
We need a whole new language with everything we've learned over the past twenty years included, with cleaner syntax, rather than bits stuck on at odd angles.
|
|
|
|
|
The "best" part is that, like out-with-declaration, the declaration pollutes the scope surrounding the if. That's also annoying about the old pattern of using as and checking whether the result is null, but this new syntax syntactically suggests that it solves that long-standing annoyance and it doesn't.
|
|
|
|
|
I agree with a desire to not pollute the scope with rubbish. On the other hand, maybe defining a new scope is the better solution -- define a new Method.
In so many cases, when a scope becomes polluted, it's a side-effect of not splitting the logic into enough granularity.
It seems like maybe C# needs a with statement  . Or maybe not, I've never liked the with statement in languages which include it. But if C# could get with right, maybe even I would use it.
|
|
|
|
|
|
Which is not a with statement.
|
|
|
|
|
And what is a with statement
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
) code that goes overboard with the more concision-focused syntax that OP mentions. Doesn't help that VS is constantly underlining anything that can be converted to a ternary or expression-bodied member. 
Don't get me wrong, these two things have their place, and the corresponding auto-fixes should be right there in the editor context menu, but their possibility shouldn't trigger the code underlining... ![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)