Walter Bright:

> The @nogc logic is entirely contained in the front end, and is not affected by back end logic.

Thank you for your answer and sorry for me being sometimes too much nervous.
So the problem I was alarmed about doesn't exists.

Some time ago I have filed this ER:
https://issues.dlang.org/show_bug.cgi?id=12642

That shows this rejected code that I thought could be accepted:

__gshared int[1] data1;
int[1] bar() @nogc {
    int x;
    return [x];
}
void main() @nogc {
    int x;
    data1 = [x];
    int[1] data2;
    data2 = [x];
}


So that's an example of what you are talking about. DMD is already performing some stack allocation of array literals that the @nogc is not seeing and rejecting.

Kenji Hara has commented:

> If you remove @nogc annotation, all array literals will be
> allocated on stack. So this is pure front-end issue,
> and may be fixed easily.

So the ER 12642 should be a wontfix, or a front-end rule should be added to be added so all D compilers allocate those cases on the stack.

If I am not missing some more point, what is the best solution?

Bye,
bearophile

"Jacob Carlborg"  wrote in message news:ljfvec$126l$1@digitalmars.com...

> That's a problem. The problem is if someone has an idea/code it wants to be merged, it's enough to convince one developer with push right to get it merged.

At least these days it only happens when Walter and Andrei agree instead of just Walter merging whatever he feels like. 

> If I am not missing some more point, what is the best solution?

Before this question gets lost, I'd like to receive some kind of answer.

Thank you,
bearophile

On 04/27/2014 01:32 AM, bearophile wrote:
>> If I am not missing some more point, what is the best solution?
>
> Before this question gets lost, I'd like to receive some kind of answer.
>
> Thank you,
> bearophile

The front end already distinguishes dynamic and static array literals (in a limited form), this distinction should simply carry through to code generation and static array literals should be allowed in @nogc code.

Here's another thing that should be allowed that doesn't depend on optimizations:

Any code path in a @nogc function that is guaranteed to abort the program should be exempt from @nogc enforcement. This includes assert(0) and throwing an Error.

Take std.exception.assumeWontThrow() as an example:

T assumeWontThrow(T)(lazy T expr,
                     string msg = null,
                     string file = __FILE__,
                     size_t line = __LINE__) nothrow
{
    try
    {
        return expr;
    }
    catch(Exception e)
    {
        immutable tail = msg.empty ? "." : ": " ~ msg;
        throw new AssertError("assumeWontThrow failed: Expression did throw" ~
                              tail, file, line);
    }
}

Currently, this cannot be @nogc, because it uses `new` and `~`. However, this only happens in preparation to throwing the AssertError, which in turn causes the program to abort. I guess in this situation, it's ok to allocate on the GC heap.

With my proposed rule, assumeWontThrow can be deduced to be @nogc iff expr is @nogc. This allows more functions to be @nogc.

On 2014-04-26 16:43, Daniel Murphy wrote:

> At least these days it only happens when Walter and Andrei agree instead
> of just Walter merging whatever he feels like.

Yeah, but it's still a problem when the rest of the community disagrees.

-- 
/Jacob Carlborg