On Tuesday, 30 September 2014 at 09:13:02 UTC, ixid wrote:
> I also suspect Andrei is doing a major project at the moment which is making him uncharacteristically harsh in his responses, from his POV he's doing something massive to help D while the community has gone into a negative mode.

There are only two kinds of languages: the ones people complain about and the ones nobody uses. The "negative mode" will likely become more negative as D continues to grow in popularity.

On 9/30/2014 2:13 AM, ixid wrote:
> It might be an effective argument to give bearophile some of the
> problematic code and see what his idiomatic D version looks like and if
> what you're after is elegantly achievable.

Or heck, ask the n.g. Lots of people here are very creative in their solutions to various D problems.

You've shown me code that is essentially "I want to do XYZ with ref" but it's still at a low level - step up a layer or two.

On Tuesday, 30 September 2014 at 08:33:27 UTC, Trass3r wrote:
> On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote:
>> Also, inferring everything is quite
>> expensive and we want D to compile fast.
>
> Doesn't the compiler have to do that anyway?
> I'd expect a proper compiler to check if my code is actually what
> I claim it is. It's quite easy to mark something as e.g. nogc in
> the first version and later on add code with allocations.

It is for the function body, but most qualifier are transitive,
so depends on the inference on other function.

On Monday, 29 September 2014 at 00:51:26 UTC, Walter Bright wrote:
> On 9/28/2014 5:38 PM, Manu via Digitalmars-d wrote:
>> That said, my friend encountered one of my frequently recurring pain
>> cases himself yesterday:
>> struct S(T...)
>> {
>>   void f(T args) {}
>> }
>>
>> S!(int, ref S) fail; // <-- no clean way to do this. I need this very
>> frequently, and he reached for it too, so I can't be that weird.
>
>   S!(int, S*)

Yet another solution...

http://dpaste.dzfl.pl/e28c55416ce2

... locally you always use ref, but when instantiating another template you need to forward the original pointer type to the next level... this way it's possible to avoid an explosion of "static if":s.