On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot <[email protected]> wrote:
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
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.
Which is the very reason why I was so insisting of defining exact set of
cases when optimisation is to be guaranteed in spec (before releasing
@nogc). Unfortunately, with no success.
Well, @nogc is not released yet. Please tell me we don't have to avoid
breaking code based on git HEAD...
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?
There are no user-defined attributes that can possibly fail on only some
compiler. And compiler-specific attributes are part of that compiler
documentation and never part of language spec. This is the difference.
But such a situation would not violate a spec that says "@nogc means there
are no hidden GC calls." And the end result is identical -- I must compile
function foo on compiler X only.
I agree there are likely no precedents for this.
Another option would be to put such a compiler-specific attribute around
the code in question rather than a different attribute than @nogc on the
function itself. I think there's really no avoiding that this will happen
some way or another.
-Steve
