Does D have too many features?

[Alex Rønne Petersen]

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