@future attribute / @future keyword?

[Mathias Lang]

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.