Does D have too many features?

[foobar]

On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote:
> [...]
> I disagree. Having a dedicated foreach construct allows the 
> compiler to
> optimize away the delegate in certain cases. I wouldn't want to 
> incur
> the cost of creating and passing a delegate in something as 
> simple as
> foreach (i; 0..100), for example.
>
>
compiler inlining?
There is no reason why this should be special cased for a 
specific redundant construct in the language. Shouldn't I enjoy 
similar optimization techniques when using other kinds of 
functions with delegate parameters?

>> * enum - enum should be completely redesigned to only implement
>> what it's named after: enumerations.
>
> Actually, I rather like the enum idiom of declaring compile-time
> constants. Though it could do with a renaming to something more
> befitting.
>
>
>> * version - this does not belong in a programming language. Git
>> is a much better solution.
>
> This is an interesting idea. But using separate git branches 
> just for
> having versioned code seems a bit like total overkill... plus a
> maintenance nightmare since you have to continue pull and merge 
> changes
> to every porting branch every time development happens. Whereas 
> having
> everything represented in source means that whoever writes a 
> new feature
> is also responsible for making it work with whatever versions 
> are
> currently out there. After-the-fact fixes are always painful.
>
>
>> * di files - a library should encapsulate all the info required
>> to use it. Java Jars, .Net assemblies and even old school; 
>> Pascal
>> units all solved this long ago.
>
> I proposed a while ago that .di files should be replaced by 
> something
> better: omit ALL function bodies, template bodies, private 
> members,
> etc., and just keep the "real" public API in the human-readable 
> part of
> the file. Function and template bodies should be kept in as a 
> binary
> blob readable by the compiler (which obviously needs to know 
> them
> otherwise it won't be able to expand templates).
>
> (Yes the binary blob can be reverse-engineered, but so can 
> executables,
> so it's a moot point. We're not trying to write cryptographic 
> security
> here, but it's nice to separate what the compiler needs to know 
> vs. what
> the user of a library needs to know.)
>
>

I agree with the general notion here. Whatever the actual 
implementation details are, the API should be strongly tied to 
the binary in order to insure consistency and ease of use. I 
shouldn't need to worry if the header files match the binary 
library. Regarding the human readable API - that's why we have 
documentation for.

>> * This is a big one: get rid of *all* current compile time
>> special syntax. It should be replaced by a standard compilation
>> API and the compiler should be able to use plugins/addons. This
>> would reduce the size of the language to half of its current
>> size, maybe even more.
>
> I have to disagree here. CTFE and compile-time features is a 
> major
> reason I like D. I argue rather that compile-time features 
> should be
> *improved*. The current situation is good, but not quite there 
> yet. It
> can be made better.
>
>
> T

Please see my other reply to Timor. "compile-time" is simply the 
run-time of the compiler and shouldn't require any special 
syntax. E.g. D currently requires me to use pragma to output a 
message during compilation whereas I think it would be much 
cleaner to simply use writeln() in a component loaded and run by 
the compiler during compilation of my target code.