ch-ch-changes

[Don]

grauzone wrote:
> One thing about std.algorithm: you really seem to like using 
> compile-time strings as literals. However, this makes the use of 
> delegates harder. For example, to use a delegate, you need to do this 
> (quoted from your docs):
> 
>  > int[] a = ...;
>  > static bool greater(int a, int b)
>  > {
>  >     return a > b;
>  > }
>  > sort!(greater)(a);  // predicate as alias
> 
> In my opinion, doing something like
> 
>  > sort(a, (int a, int b) { return a > b; });
> 
> would be simpler and more intuitive than passing a delegate name as 
> template parameter. (The delegate literal syntax still could be 
> improved, though.)
> 
> Does std.algorithm work with closures at all? I see that the greater() 
> function in your example is marked as static. (Sorry, I didn't test it 
> myself.)
> 
> 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.

> 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:

static if(__traits(compiles, mixin(comp) )) {
   mixin(comp);
} else {
    // static assert is a bit broken,
    // better to do it this way to provide a backtrace.
    pragma(msg, "Bad predicate: " ~ comp);
    deliberate_error_message; // t
}

into std.functional. Which will generate a very controlled error message.
(Doesn't work if the predicate contains mismatched parentheses, but 
that's fixable).
The language changes required to give a perfect solution to this are 
pretty small (just get static assert() to give the instantiation point 
of each template which instantiated it, create a version of traits which 
, given a string, tells you if it would compile if it were mixed in).

Then we get:
static assert(__traits(mixincompiles, comp), "Predicate: " ~ comp ~ " 
does not compile");

mxin(comp);


  How will runtime
> debugging work? Will the debugger be smart enough to point me to the 
> correct source code location, if there happens a segfault in my 
> predicate? I'm sure it could, if you used delegates instead.
> 
> Why did you make this so complex? What's your position on this? Do you 
> agree that there are problems, or are you happy with how it is?
> 
> Why did you choose to do it like this? Because it is shorter, or for 
> performance (avoid delegate call)? 

It's a LOT faster than delegates.


Does it enable some weird use cases,
> which wouldn't be possible when using delegates?
> 
> Regarding performance: I don't think performance justifies all these 
> problems. Standard library functions should be as fast as possible, but 
> this goal should come second after robustness and simplicity.
> 
> Another problem is, that using string mixins seems to be quite 
> problematic, because they are mixed in in a different scope. If I'm not 
> mistaken, you can't do this:
> 
>  > int foo(...) {...}
>  > sort!("foo(a, b);");
> 
> You might think that "sort!("a>b", a);" is elegant and short, but this 
> probably only works out in toy-examples.

String mixins are only intended to be used in simple cases. If it's not 
simple, you can use a delegate, because the overhead becomes a small 
part of the cost.

> 
> And macros, which are supposed to magically cure all those problems, 
> were postponed to D3.0.
> 
> I'm also worried about compile times. You use nested templates with 
> string mixins, which only can be slower to compile than using e.g. the 
> builtin .sort. I don't know if this a problem, but in my opinion, 
> compile times are already high enough. Times will add up!

The CTFE bug still needs to be fixed.

> 
> 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.