On 4/26/17 4:32 AM, Olivier FAURE wrote:
On Tuesday, 25 April 2017 at 18:32:09 UTC, Steven Schveighoffer wrote:
I missed this part. Now that I read that, I think we aren't going to
gain much by having this language feature internal to the compiler.
The way I understood it, the feature will only stay internal to the
compiler until it's deemed "safe" for general use.
The question I have is: who is going to adjust this list? If the answer
is nobody, then when is it deemed "safe" for general use? How do we
judge whether it's safe to allow others to use it, when nobody is using it?
What's more useful to me is to require the @future attribute on all new
symbols in object.d, and then see how that process works. Given that the
very nature of @future is that it's supposed to be temporary, then if we
decide it's not worth the hassle, we can just abandon the feature.
If we want to limit usage, what I'd *rather* see is that the @future
(or TBD attribute) only has special meaning inside object.d. Having to
adjust a hard-coded compiler list seems like it will result in zero PR
changes (save the one that prompted this DIP) that might give us any
insight into whether this is a useful feature.
The proposal does include something like that.
I may have missed it. There's a lot of text, it's hard to see what is
actually being proposed and what isn't.
Alternatively, if it proves to be simpler to implement, the feature
can be added as an attribute with reserved double-underscore prefix
(i.e. @__future) with compiler checks ensuring that it is not used
outside of core.*/std.*/object modules. If that course of action is
chosen, such an attribute should be defined in the core.attribute
module of DRuntime.
I'm wondering if you actually wrote this? It seems to be quoted.
Sure, we can allow such a thing, and prepending double underscores seems
like a reasonable thing, since this should be used lightly and infrequently.
-Steve
