[OT] Sharp Regrets: Top 10 Worst C# Features

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 19 August 2015 at 02:08:08 UTC, H. S. Teoh wrote:
> The point about the empty statement (#10) is interesting... 
> never really
> thought about it before.

I think that D pretty much solved this by enforcing {} for if 
statements and loops. so, it's not particularly error-prone in D, 
and unlike C#, D does have stuff like labels where an empty 
statement is required, and AFAIK, debuggers won't treat {} as a 
statement, unlike ;, so I don't think that you can set a 
breakpoint on {}, whereas you can on ;. So, I really think that 
D's approach is the right one.

> #9 is something that D (almost) gets right: it's generally a 
> bad idea to make <, <=, ==, >, >= individually overloadable 
> (ahem, C++), 'cos it's a lot of redundant typing (lots of room 
> for typos and bugs) and most combinations don't make sense 
> anyway. D did the right thing by consolidating <, <=, >, >= 
> into opCmp. However, D still differentiates between opCmp and 
> opEquals, and if those two are inconsistent, strange things 
> will happen. Andrei's argument is that we want to support 
> general partial orders, not just linear orders, but IMO this 
> falls in the "too much flexibility for only marginal benefit" 
> trap. I mean, when was the last time you badly needed a partial 
> order to be expressed by *built-in* comparison operators, as 
> opposed to dedicated member functions?  When people see <, <=,
> >, >= in your code, they generally expect the usual linear
> order of numerical types, not something else. This causes 
> confusion and suffers from the same problems as using + for 
> string concatenation.

The main reason to have opEquals and opCmp separate is because 
there are many types for which equality makes sense but ordering 
doesn't. The other is that opEquals is almost certainly going to 
implement == more efficiently than opCmp could. And given how 
common an operation == and != are, I wouldn't want to see opCmp 
used in place of opEquals when opCmp is defined. It's not that 
hard to get the comparison operators right, especially when you 
only have two functions to worry about. Yes, you potentially 
still have a chance of a having a consistency problem as a 
result, but it's _far_ smaller than you'd get in C++ or C#. I 
think that what D has strikes a good balance.

But I do think that that whole deal about partial ordering is 
just bizarre. If == is true, <= and >= should always be true and 
vice versa. Similarly, if any of them are false, all three of 
them should be false. If you want to do something else, then 
don't use the built-in operators.

> #8: ah, the good ole controversial bitshift operators... esp. 
> the still unresolved controversy surrounding the behaviour of
> >> vs. >>> (sorry, forgot the bug number, but it's in
> bugzilla).  IMO, we should ditch these operators and use int 
> intrinsics for the assembly instructions instead. What's the 
> use of built-in operators that are only occasionally used in 
> system code?  Something like 1.shiftLeft(2) would work just 
> fine in expressions, and simplify the lexer by having less 
> token types.

I don't see much point in not having << and >> and having a named 
function instead. A don't see how it would gain anything at all, 
particularly given that << and >> are already well-known, and 
everyone who was looking to bitshift would just get annoyed and 
confused if they weren't there.

> #7: did C# copy delegate literal syntax from D, or did D copy 
> from C#?

D copied it from C#.

- Jonathan M Davis