91–100 of 124 posts
Uhmmmm....I'm a professional C++ programmer who uses switch statements quite a lot and no, I couldn't instinctively tell what it was doing straight away. Am I being dumb?
Earlier quoted context omitted.
They aren't real guarantees in TypeScript, because the type system doesn't guarantee anything about the actual values that are flowing through the system. i.e. you have to code everything in TypeScript and make sure everyone follows the best practices.
Most statically-typed languages don't verify types at runtime either. As long as you enforce types at the boundaries between typed and untyped code, you should be fine. And enforcing invariants at the boundaries of your code is pretty important for all languages.
Earlier quoted context omitted.
AFAICT, this is kind of true for a lot of F#: F# is where they do the experimentation, C# is where they do the more heavily engineered "fast" version.
That seems to be true at least to some extent. However, there are some noteworthy parts of the two languages that seem to be intentionally different. For example, F# optimizes tail recursion while C# doesn't.
"The new switch expression is quite simple. Anyone familiar with the switch statement can say what the following code is doing" Uhmmmm....I'm a professional C++ programmer who uses switch statements quite a lot and no, I couldn't instinctively tell what it was doing straight away. Am I being dumb?
Earlier quoted context omitted.
Actually, adding LINQ to C# did not introduce any new functionality at all. Everything you can do in LINQ you could already accomplish in C# without LINQ. Yes, I suppose someone could say that the older code was uglier, but it already had the same capabilities as LINQ. That's been the case for the majority of supposed "new features" in C# for at least the past 8 years or so -- LINQ, inline variables, anonymous functi…
That's the general nature of a turing complete language. The purpose of every feature is making things less ugly.
I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.
I think I agree. I used to write a lot of C# v2 and loved it. There didn't seem to be anything 'missing'. Each version since then has added nice things but are they really necessary? Now the language looks huge and complicated and because of that, I'm not sure I'd ever want to use it again.
I agree with other posters that this introduces a new style, but when I look at C# 2.0 I see a language I do not want to use anymore. It is old and clumsy. Like Java :)
"+" => ((Func )(() => { Log("addition"); return a + b; }))(), This is incredibly ugly. Why couldn’t it be “+” => {stuff}
Rather than adding syntax for it, the sane approach would just be to generalize the functionality. T Log (string msg, Func func) { Log(msg); return func(); } var result = operation switch { "+" => Log("addition", () => a + b), "-" => Log("subtraction", () => a - b), "/" => Log("division", () => a / b), _ => throw new NotSupportedException() }; This is shorter, cleaner, and how most folks would actually write somethin…
T Log(string msg, T result) {
Log(msg);
return result;
}
var result = operation switch {
"+" => Log("addition", a + b),
"-" => Log("subtraction", a - b),
"/" => Log("division", a / b),
_ => throw new NotSupportedException()
};
I just mention it for academic interest. To be honest, I find the idea of passing a parameter to Log() (whether it's the value or the function) that your don't actually want logged, so that you can shoehorn two statements into an expression, abhorrent. Just write the two statements out! I think an old-fashioned switch statement is the right tool here.
Earlier quoted context omitted.
String.Format("Is {0} to read {2} {1} of the {3} out of place", "harder", "half", "because", "string is").
Ironically that’s actually also one of the key advantages of it. If you have a long string with many placeholders in it and need to add a new one in the middle... you just add it and don’t have to figure out where in the list of params to insert the new arg.
Earlier quoted context omitted.
C# 2 did not have Linq. Linq is the best feature ever.
Actually, adding LINQ to C# did not introduce any new functionality at all. Everything you can do in LINQ you could already accomplish in C# without LINQ. Yes, I suppose someone could say that the older code was uglier, but it already had the same capabilities as LINQ. That's been the case for the majority of supposed "new features" in C# for at least the past 8 years or so -- LINQ, inline variables, anonymous functi…
Earlier quoted context omitted.
Rather than adding syntax for it, the sane approach would just be to generalize the functionality. T Log (string msg, Func func) { Log(msg); return func(); } var result = operation switch { "+" => Log("addition", () => a + b), "-" => Log("subtraction", () => a - b), "/" => Log("division", () => a / b), _ => throw new NotSupportedException() }; This is shorter, cleaner, and how most folks would actually write somethin…
I don't know a great deal of C#, but couldn't you just do: T Log (string msg, T result) { Log(msg); return result; } var result = operation switch { "+" => Log("addition", a + b), "-" => Log("subtraction", a - b), "/" => Log("division", a / b), _ => throw new NotSupportedException() }; You already have a lambda for calling Log(), no need for a second to call the inner function. This does change the order of evaluatio…