Does D have too many features?

David Nadlinger see at klickverbot.at
Sun Apr 29 05:26:12 PDT 2012


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


More information about the Digitalmars-d mailing list