On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot <pub...@dicebot.lv>
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...
It has become a blocker for next release though. It has been
repeated numerous times that such features need to be developed
in own feature branches until design is considered at least
somewhat solid =/
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.
It is invalid and useless spec on its own. It would have been a
valid spec if it also had a chapter with definitive list of all
cases when hidden GC calls can happen and when are guaranteed to
be optimized away. Otherwise such spec is as useful as one that
says "Maybe your code will compile".
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.
I think there should be both. Saying that you need to marry
specific compiler forever once you want to use @nogc is pretty
much same as saying "don't use @nogc".
