On 4/25/17 12:24 PM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Apr 24, 2017 at 04:58:12PM +0100, rikki cattermole via Digitalmars-d
wrote:
On 24/04/2017 4:03 PM, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
[...]
This DIP concerns me, for any other language I would go so far as to
saying, I would expect people to overuse this to the extreme. Going by
what they "think" they may need in the future instead of what they
definitely will need.
Initially I also had the same concern, but after reading the DIP in its
entirety, I think it may be worth considering. The DIP, as it stands,
proposes to make this feature available *only to the compiler* as a
hard-coded list of symbols, meaning that in its first incarnation it
will only be used for adding new symbols to e.g., druntime.
*If* it passes this first round of implementation / general usage in the
D community, then a followup DIP can be made to make this feature
available to the general user. But if any major issues arise in this
first stage, we can simply forego further implementation, perhaps even
revert the feature.
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.
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.
If this DIP does not address the actual language, I would vote no. You
can always make a special case solution in the compiler without a DIP.
On the flip side, it would be great for development, feature not yet
done but planned? Annotate it. Even before a release ever happens.
[...]
This is good and bad. If overused, it could lead to the situation you
described, where people aggressively "reserve" future symbols that
eventually turn out to be unnecessary, thus potentially "wasting" good
names in the namespace.
I think this is not really that big of a deal. Other than object.d,
there's nothing people absolutely have to include. Just don't import
libraries that abuse this, and you won't have this problem.
I'd also hazard to guess that a very popular project that abused this
feature would simply develop forks which didn't.
-Steve
