ch-ch-changes

[Don]

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.