A betterC modular standard library?

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote:

Mir uses deprecated native complex numbers because we can not 
spend days explaining why they are better then std.complex (in 
short: std.complex breaks compiler optimization logic, function 
inlining works, but it breaks optimization logic). I have already 
spend 4 hours for forum discussions and PRs about this issue 
without any result.

We are doing the best things we can do with current D. If 
something will be improved in future we will upgrade codebase.

> P.S. a good example of the sort of statement that needs more 
> explanation, at least for me:
>> The betterC
>> std.range and std.algorithm analogs would be released with new 
>> ndslice
>> implementation. Mir's algorithm would be faster then Phobos 
>> and will
>> generate less template bloat."
> How? Why? Is ndslice actually capable of the same level of 
> flexibility as std.algorithm and std.range? You're effectively 
> saying "all that stuff that Andrei (and others) designed and 
> wrote, I can do better" without really showing anyone why they 
> should believe that.

The explanation of new idioms will appear after its code.

I did not say "better". I said "betterC" plus "faster".

Yes, i can say that for DCV library new idioms are much better 
then Phobos.

But new idioms have another issues, for example D language is not 
capable to infer their safety for many of them. Other issues is 
that there a lot of fast non CTFE-able types and their CTFE-able 
analogs.

One good things for safety and CTFE is allow multiple return 
value. In combination with `auto ref` it is _very_ powerful:

----
auto ref front()
{
   // Returns 2 values, each value is returned by reference if 
possible
   return (a.front, b.front);
}
----

This would be interesting to discuss and to have it in D in CTFE 
and @safe mode. But I am not good in DIPs.

This sorts of features is very desirable.