Does D have too many features?

[H. S. Teoh]

On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
[...]
>  - 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).

+1. The voice of reason.


[...]
>  - 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).

I found hexstrings useful for writing unittests for testing Unicode
handling (I wanted to test both big- and little-endian UTF-16 and
UTF-32, whereas currently string literals can only produce native
endian). It might also be useful for unittesting code that takes binary
input.


> As for r"", every time I actually need WysiwigString, I use backticks,
> because such strings often contain quotes anyway.

+1. I think r"" and `` should be merged. Having both is too much.


> 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.

I use tokenstrings a lot for mixins. But arguably that use case would be
obsolete when D finally finds a good macro system.


[...]
>  - Concatenation of adjacent strings: Also an anti-feature, imho.

I personally find them useful for nicely-formatting code that contains
lots of long strings. But YMMV.


>  - 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?

Yeah when I was writing a D lexer (just as an exercise) I was
flabbergasted at the sheer amount of comparison operators D has. I mean,
I don't know if I will ever use *half* of them in my lifetime. After a
while my eyes were just glazing over from all the ASCII UFO's that
somehow flew into my code from outer space.

If IEEE-754 support is what the intention was, I'd recommend putting
them in std.math instead of loading the language with a bunch of
apparently-oxymoronic operators like !<> and !<>=, that probably nothing
outside of IEEE-754 buffs will ever even care about.


[...]
>  - 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.
[...]

AA's are moving into druntime. Yours truly is supposed to make that
happen eventually, but lately time hasn't been on my side. :-/

This is an interesting idea, though... once we've fully excised AA's
from dmd (aside from convenient lowerings from native syntax), it will
open up the possibility of writing a GC-less druntime replacement that
also provides an alternate implementation of AA's that don't depend on
the GC.


T

-- 
This is not a sentence.