I have read about @future before being some kind of opposite of deprecated. However when trying to search about it now again I can't find any mentions of it anywhere except on https://dlang.org/spec/traits.html#isFuture

It's difficult enough to search for "future" but even if limiting it to the spec it's the only search result: https://www.google.com/search?domains=dlang.org&sourceid=google-search&q=%40future&sitesearch=dlang.org%2Fspec

There is this "future compiler concept": https://forum.dlang.org/post/hjdstwzhcbrektlijvhm@forum.dlang.org
which now is however leads to a dead link, so here is a fixed link: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1007.md

In the grammar @future isn't mentioned at all, has it been removed from the language but the trait was left over?

Maybe the documentation here should be improved to avoid confusion.

It never used @future, looks like that was only a suggestion in the dip. It also suggested @__future which it seems it was implemented with that.

https://github.com/WalterBright/dmd/blob/2d4c7d4ed37645ed9d62e5e1a6652e5ae5b1fb26/test/runnable/future.d

On 3/18/20 6:20 AM, WebFreak001 wrote:
> I have read about @future before being some kind of opposite of deprecated. However when trying to search about it now again I can't find any mentions of it anywhere except on https://dlang.org/spec/traits.html#isFuture
> 
> It's difficult enough to search for "future" but even if limiting it to the spec it's the only search result: https://www.google.com/search?domains=dlang.org&sourceid=google-search&q=%40future&sitesearch=dlang.org%2Fspec 
> 
> 
> There is this "future compiler concept": https://forum.dlang.org/post/hjdstwzhcbrektlijvhm@forum.dlang.org
> which now is however leads to a dead link, so here is a fixed link: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1007.md
> 
> In the grammar @future isn't mentioned at all, has it been removed from the language but the trait was left over?
> 
> Maybe the documentation here should be improved to avoid confusion.

Honestly, I think that concept was never fully implemented (or maybe followed properly). Simply because there has not been much complaint about symbols being added "too quickly".

99.99% of the time, you add a symbol to a module, and there are no ill effects. The problem at the time was a significant one for Sociomantic, I believe because of a change that they needed for switching from Tango to druntime.

If you grep druntime, there are 2 usages, both from about 2-3 years ago. Both were either submitted by sociomantic, or asked to add the @__future attribute from them.

I'm guessing that either interest was lost in keeping this up, or didn't notice when things were added, and it didn't affect them. Seems like all the focus was on the exception hierarchy (which needs TLC anyway). Maybe someone from that org can identify how this has helped them.

The whole concept itself has some rather obscure use cases. Perhaps in the future there will be an obvious use case, and we will be glad that we have it.

-Steve

On Wednesday, 18 March 2020 at 14:23:28 UTC, Steven Schveighoffer wrote:
>
> Honestly, I think that concept was never fully implemented (or maybe followed properly). Simply because there has not been much complaint about symbols being added "too quickly".
>
> 99.99% of the time, you add a symbol to a module, and there are no ill effects. The problem at the time was a significant one for Sociomantic, I believe because of a change that they needed for switching from Tango to druntime.
>
> If you grep druntime, there are 2 usages, both from about 2-3 years ago. Both were either submitted by sociomantic, or asked to add the @__future attribute from them.
>
> I'm guessing that either interest was lost in keeping this up, or didn't notice when things were added, and it didn't affect them. Seems like all the focus was on the exception hierarchy (which needs TLC anyway). Maybe someone from that org can identify how this has helped them.
>
> The whole concept itself has some rather obscure use cases. Perhaps in the future there will be an obvious use case, and we will be glad that we have it.
>
> -Steve

Yep that feature is completely under-documented. It ended up being important to Sociomantic because we introduced `message` in `Exception`, as our `Exception` are reusable and use a buffer to minimize allocations, but said `message` broke a bunch of code because other `Exception`-derived class had implemented their own method that clashed with that very common name. In addition, some shadowing might have been involved at the time, which made the issue painful to track down.

It is less important to mainstream D than it was to Sociomantic mainly due to the differences in our approaches. Sociomantic code relied heavily on OOP, while mainstream D does not. New symbols in Phobos are rare, and rarely conflict with other modules. Adding a new overload in an overload set is guaranteed to not conflict since the change from protection to visibility.

I like to see it this way: Any new virtual function (and potentially new field) in a derived class relies on the absence of such name existing in any of its ancestor. If it does exist, or is introduced, the compiler will complain about `override` not being used. On the other hand, a new symbol in a module does not have this requirement (there is still potential for breaking change: e.g. if you introduce an overload that conflict, for example adding a `const(char)[]` overload to a function that has a `const(char)*` overload and no `string` overload).

To answer the OP: It is still in the language, and there's a test for it in druntime (https://github.com/dlang/druntime/blob/master/test/exceptions/src/future_message.d). But yeah, no one uses it.