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.