grauzone wrote:
Don wrote:
Using string mixins messes up syntax highlighting
I think the argument that a language should be designed around the
limitations of an IDE designed for a different language is a weak one.
Especially with the greatly improved support for string mixins which
just got added in the last version of Descent.
So all IDEs should contain a D compiler?
Of course they should contain a D front-end. Otherwise, you might as
well use a text editor. Most IDEs at present are using a Java front-end
with minor modifications, so of course they are not going to support
things properly.
But let's forget this, it's a
minor issue, and it will/can be fixed with magic AST macros or special
kinds of string literals.
Indeed.
and the code is more obfuscated. If you make an error in your
predicate, random funny things internal to the library implementation
could happen, and the compiler will spurt out indecipherable error
messages for random modules (I guess in this case, std.algorithm or
std.functional).
Not necessarily. Andrei can just add:
Then he should do it. If not, it becomes a
theoretically-fixable-but-in-reality-ignored issue, which causes
unnecessary frustration to innocent programmers.
It really deserves a couple of compiler fixes.
Note that metaprogramming error messages in D are generally NOT as
terrible as the ones in C++, anyway.
For one, I'm sure that this will generate an additional gazillion of
nearly useless linker symbols with very long names.
No. That happens with templates, not CTFE. Excluding the CTFE bug, of
course.
Has nothing to do with CTFE. For example, the following code
> void foo(char[] T)(int x) {}
> void main() { foo!("hello")(3); }
Will produce an object files, which contains the following symbol:
> _D1g25__T3fooVG5aa5_68656c6c6fZ3fooFiZv
Yes, that's a template!
I don't know if this will ever become an issue, but optlink.exe already
crashes often enough.
