DIP 1007 is titled "'future symbol' Compiler Concept".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md

All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.

Thanks in advance to all who participate.

Destroy!

On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
> DIP 1007 is titled "'future symbol' Compiler Concept".

«In all the mentioned languages but D, a common convention is to only use unqualified access for symbols in the standard library.»

Not quite right for C++. The common convention in modern C++ is to use full std::name qualification for the standard library. It is common to use unqualified access for the local namespace(s) only.

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
>
> All review-related feedback on and discussion of the DIP should occur in
> this thread. Due to DConf taking place during the review period, the
> period will be extended by a week. The review period will end at 11:59
> PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
> complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP
> will be scheduled for another round. Otherwise, it will be queued for
> the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

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.

On the flip side, it would be great for development, feature not yet done but planned? Annotate it. Even before a release ever happens.

Although I would prefer to see a unifying syntax to merge deprecated and this into it, making it more user configurable. More complex to design but most importantly less special rules in language.

On Monday, 24 April 2017 at 15:22:15 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
>> DIP 1007 is titled "'future symbol' Compiler Concept".
>
> «In all the mentioned languages but D, a common convention is to only use unqualified access for symbols in the standard library.»
>
> Not quite right for C++. The common convention in modern C++ is to use full std::name qualification for the standard library. It is common to use unqualified access for the local namespace(s) only.

In headers. Not in source files, and I don't know why anyone would want to keep typing `std::` all the time. Do some people do what you're describing? Yes, but I see no evidence that that's the common convention in modern C++. In fact, from the core guidelines:

"
##### Example

    #include<string>
    #include<vector>
    #include<iostream>
    #include<memory>
    #include<algorithm>

    using namespace std;

    // ...

Here (obviously), the standard library is used pervasively and apparently no other library is used, so requiring `std::` everywhere could be distracting."

Never mind the monstrosity that would be trying to use the C++ user-defined literal without `using namespace std`:

#include <string>
using namespace std::operator""s;  // Argh! My eyes!

No thanks. I even had to look that up, and I'll probably forget it.

On Monday, 24 April 2017 at 22:22:14 UTC, Atila Neves wrote:
> In headers. Not in source files, and I don't know why anyone would want to keep typing `std::` all the time.

C++ is increasingly becoming dependent on templates so header files are expanding at the cost of ".cpp source files". If more than half the code base is in header files then it makes little sense to not use "std::" fully qualified, both for clarity, name-resolution and usability reasons (cut and paste).

(For templates the core guidelines says that one should use "std::" and only use unqualified names for situations where you want to override the "std::" provided definition with a local implementation if it exists.)

> Never mind the monstrosity that would be trying to use the C++ user-defined literal without `using namespace std`:
>
> #include <string>
> using namespace std::operator""s;  // Argh! My eyes!

You could just wrap that up in an application level string header.

On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
> DIP 1007 is titled "'future symbol' Compiler Concept".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>
+1
I like the idea of beeing warned about new symbols in libraries, so that I can change my symbols ahead.

On 2017-04-24 17:03, Mike Parker wrote:
> DIP 1007 is titled "'future symbol' Compiler Concept".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>
> All review-related feedback on and discussion of the DIP should occur in
> this thread. Due to DConf taking place during the review period, the
> period will be extended by a week. The review period will end at 11:59
> PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
> complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP
> will be scheduled for another round. Otherwise, it will be queued for
> the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

How is this supposed to be used?

* Take the example of the recent __cmp addition to object.d, would we say: "this PR has to wait one year because we need to add the @future attribute and let users update their code"?

* When the @future attribute is added, would one add it on a dummy symbol or would one provide the implementation as well?

* If the implementation is provided, is it possible to use the symbol by the users the symbol was added for in the beginning? In the above example that would be the compiler generating a code to __cmp

-- 
/Jacob Carlborg

On 25/04/2017 12:29 PM, Jacob Carlborg wrote:
> On 2017-04-24 17:03, Mike Parker wrote:
>> DIP 1007 is titled "'future symbol' Compiler Concept".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>>
>> All review-related feedback on and discussion of the DIP should occur in
>> this thread. Due to DConf taking place during the review period, the
>> period will be extended by a week. The review period will end at 11:59
>> PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
>> complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> How is this supposed to be used?
>
> * Take the example of the recent __cmp addition to object.d, would we
> say: "this PR has to wait one year because we need to add the @future
> attribute and let users update their code"?

Mitigation:

version(none) {
	void foo() {
		...
	}
} else {
	@future
	void foo();
}

On 4/25/17 7:29 AM, Jacob Carlborg wrote:
> On 2017-04-24 17:03, Mike Parker wrote:
>> DIP 1007 is titled "'future symbol' Compiler Concept".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>>
>> All review-related feedback on and discussion of the DIP should occur in
>> this thread. Due to DConf taking place during the review period, the
>> period will be extended by a week. The review period will end at 11:59
>> PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
>> complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> How is this supposed to be used?
>
> * Take the example of the recent __cmp addition to object.d, would we
> say: "this PR has to wait one year because we need to add the @future
> attribute and let users update their code"?

__symbol is reserved by the language. I don't think we need to worry about those.

In the general case, one year is too long. A couple compiler releases should be sufficient.

>
> * When the @future attribute is added, would one add it on a dummy
> symbol or would one provide the implementation as well?

dummy symbol. Think of it as @disable, but with warning output instead of error.

> * If the implementation is provided, is it possible to use the symbol by
> the users the symbol was added for in the beginning? In the above
> example that would be the compiler generating a code to __cmp

I would think the implementation should not be provided. The idea is to reserve the symbol for future use, not to implement it. If you add an implementation and the compiler allows using that implementation, then you potentially break code. This DIP should aim not to break any code.

Really, what you are doing is reserving the overload spot. In cases where the overload would have selected your local function, then you should get no warning (as the additional symbol won't conflict). In cases where your function conflicts with a newly-reserved base class function, then the warning should be that you will eventually need to include the `override` keyword.

Actually, that brings up a problem with this, what is the mechanism to say "maybe override"? Let's say you have:

// in imported library
class Base
{
   void foo() @future;
}

// in user library
class Derived : Base
{
   void foo() {...} // triggers warning
}

What is the next step the user has to take to remove the deprecation warning, but still have valid code? If you put override on foo, it's not really overriding anything as Base.foo doesn't really exist (right?). Basically, we need a way to write Derived such that it works with both the @future reserved Base.foo, and the permanent Base.foo. With deprecation, the path is clear, you just stop using that symbol. This is not as clear.

If adding override is allowed even when base symbol doesn't really exist, that might work, but it needs to be explicit in the DIP.

-Steve

On 4/24/17 11:03 AM, Mike Parker wrote:
> DIP 1007 is titled "'future symbol' Compiler Concept".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>
> All review-related feedback on and discussion of the DIP should occur in
> this thread. Due to DConf taking place during the review period, the
> period will be extended by a week. The review period will end at 11:59
> PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
> complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP
> will be scheduled for another round. Otherwise, it will be queued for
> the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

As I mentioned elsewhere, an intermediate step for a symbol that will eventually need an override needs to be outlined. When you create a base class member that conflicts with existing derived class members, the mitigation may not simply be "you have to remove the derived function", it could also be to override the future function. How do you override a function that doesn't really exist?

I like the general idea, and it makes sense, even if it only affects a small set of files (those that are heavily imported).

-Steve