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.
