@future attribute / @future keyword?
pro.mathias.lang at gmail.com
Thu Mar 19 17:00:31 UTC 2020
On Wednesday, 18 March 2020 at 14:23:28 UTC, Steven Schveighoffer
> 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.
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.
More information about the Digitalmars-d-learn