On Fri, 25 Apr 2014 09:20:08 -0400, Dicebot <[email protected]> wrote:
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer wrote:
I don't know that it's desirable to have @nogc reject code even though
an allocation does not occur. I agree the situation is not ideal, but
@nogc is a practical optimization.
I can think of other cases where the GC may be optimized out. To reject
such code in @nogc would make it much less attractive.
It is unacceptable to have code that fails with one compiler and works
with the other despite the shared frontend version. Such "enhanced"
@nogc attributes must be placed into compiler-specific attribute space
and not as a core language feature.
Like I said, this may be the ideologically correct position, but please
explain to the poor user that even though the compiler does not invoke the
GC in his function, it still cannot be @nogc.
I think in this case, @nogc is not a good name.
But what really is the difference between a function that is marked as
@nogc that compiles on compiler X but not compiler Y, and some custom
attribute that compiles on X but not Y?
Consider that the fact that compiler X could have compiled a function that
compiler Y is linking to, may actually be @nogc, because compiler X is
better at avoiding GC calls. Wouldn't it make sense to be able to mark it
@nogc and still use it from compiler Y?
-Steve
