On 29-04-2012 14:26, David Nadlinger wrote:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
What's your list?
My personal list of features I could easily live without – some of these
might be controversial, but yes, I have written non-trivial amounts of
code in both D1 and D2:
- Anonymous nested classes: They might be useful in Java, particularly
in older incarnations, but not so much in D – never used them.
I use them. They can be useful when you're writing more object-oriented
code than functional style code.
- Comma operator: Kill it with extreme prejudice, it is an anti-feature
(allow it in for loop expressions if you really want to, but I think
there are better solutions).
+9001.
- Typesafe variadics: They look nice on paper, but I haven't used them
once. Often, you either explicitly need C-style variadics, or you want
to accept e.g. multiple ranges of the same element type, where you need
template variadics anyway.
- Unsigned right shift, but I can see how it can be useful (simply
underused?).
It's clear that arithmetic right shift is what the programmer usually
wants, and yet, we use >> to denote what they don't want. It's
completely counter-intuitive.
So, +1.
- HexString, DelimitedString, r""-WysiwigString, TokenString: I didn't
ever use the former two (for including binary data in the program,
ImportExpression is imho much easier than generating a source file
containing a HexString). As for r"", every time I actually need
WysiwigString, I use backticks, because such strings often contain
quotes anyway. Regarding TokenString(i.e. q{}) – it is certainly a very
nice idea, especially regarding syntax highlighting, and I occasionally
use them for CTFE code generation. But without any kind of support for
string interpolation, I typically find myself using normal strings for
everything except small self-contained portions of code (where mixin
templates would probably be cleaner). The problem is that can't just
»interrupt« q{}s strings to do something like »q{…} ~ identifierName ~
q{…}«, because there will most likely be unmatched braces – but this is
needed in assembling mixin strings all the time…
- Concatenation of adjacent strings: Also an anti-feature, imho.
+1.
- Floating point comparison operators like !<>= (yes, that _is_ valid D
code): I must admit that I seldom write code relying on the finer
details of IEEE-754 semantics, but can't they just be »lowered« to a
combination of the more common ones?
Why not just make them intrinsics? What are they doing in the language?
You're rarely, if ever, going to actually be using these operators
because NaN is, well, an invalid state, like null.
+1.
- »Short« floating point literals like .4 instead of 0.4 and 4. instead
of 4.0 – the saved characters are not worth the syntax special cases,
especially w.r.t. UFCS.
+1. I find it to be poor style to not include the ".0" in FP literals.
- new/delete issues have been discussed many times
- Built-in arrays and AAs: They are convenient to use, but as far as I
can see the single biggest GC dependency in the language. Why not lower
array and AA literals to expression tuples (or whatever) to make the
convenient syntax usable with custom (possibly non-GC safe) containers
as well? A GC'd default implementation could then be provided in
druntime, just like today's arrays and AAs.
Sounds reasonable.
- shared: TLS by default is great, but only __gshared is really usable
right now. IMHO, shared had better been reserved for a comprehensive
take on the subject, rather than the half-baked implementation we have
right now.
David
It's clear that shared is biased towards heavily templatized code. It's
not useful in non-templatized code because such code can't accept both
shared and non-shared values.
shared looks neat in theory, but is a fallacy in practice.
--
- Alex
