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? 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.
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.
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
I don't know if this will ever become an issue, but optlink.exe already
crashes often enough.
