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.
