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.
- 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).
- 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?).
- 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.
- 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?
- »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.
- 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.
- 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
