DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

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