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

[via Digitalmars-d]

On Wednesday, 19 August 2015 at 02:08:08 UTC, H. S. Teoh wrote:
> #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.

I see your point, but it isn't so clear cut. When you are doing a 
high level APIs, like an ORM you might want to enforce having a 
field on the left and a number on the right and return a query 
building type. So you can type "db.query(ClassA.birth < somedate)"

What would be better is to have defaults.

> #6: Hooray for std.typecons.BitFlags! :-)  On another note, the 
> remark about breaking code NOW rather than having to live with 
> a flaw for the foreseeable future of the language, surely 
> applies to D. Sure, nobody likes their code broken, but if it 
> means breaking a small number of projects today for a much 
> better language in the future, vs. not breaking anything today 
> and having to live with a huge number of projects later, I 
> think breaking code is more worth it.

Yes, if you do it in a planned manner, provide an upgrade tool, 
document changes in a "tutorial like" way and version it. E.g. 
D3, D4, D5…

> #1: D doesn't suffer from this, thanks to classes being 
> reference types by design.

I think that is the wrong argument, because surely D lifted the 
struct/class dichotomy off C#?

I think that is a C# mistake, even though the author does not 
list it. It would be better to have a reference assignment 
operator like Simula. In C everything is either a pointer or a 
value, but there is still visual confusion. In D it gets worse by 
having a proliferation of builtin types without enough visual 
cues. E.g.

a = b; // what does this do in C and D? Values, pointers, arrays…?

More clear:

a = b  // constant definition
a := b // value assignment (change fields)
a :- b // reference assignment (change pointer)

If you want references, then it makes sense to have everything be 
a reference conceptually (in terms of syntactical consistency, 
not semantics), but some are not value assignable, some are not 
reference assignable and some are both.

In general I never want to confuse value assignment with 
reference assignment, so they should be visually distinct.