On 2016-04-15 07:38, Andrei Alexandrescu wrote:
I think we should deprecate inout. For real. It costs way too much for
what it does. For all I can tell most of D's proponents don't know how
it works. -- Andrei
If "inout" is only used as a way avoid code duplication, both when
writing the code and the compiler generating the code. Then that can be
solved with two steps:
1. Improve the compiler to remove duplicated functions overloaded on
constness. That is, they generate the exact same code and and the only
difference is the constness of the functions. This is a useful
improvement regardless
2. Write a string mixin that duplicates a function three times, one for
each type of constness:
// Assuming "inout" is removed from the language and not a keyword anymore
mixin(inout(q{
inout(T)[] replaceSlice(T)(inout(T)[] s, in T[] slice, in T[]
replacement) { ... }
});
The "input" function would need to parse arbitrary D code and create
three version of the passed in function declaration, mutable, const and
immutable. In theory libdparse could be used for this but it doesn't
work at compile time. The downside is that it looks really ugly when
defining an inout function.
But, with AST macros it could look like this:
@inout inout(T)[] replaceSlice(T)(inout(T)[] s, in T[] slice, in T[]
replacement);
--
/Jacob Carlborg
